Modeling microservices using DDD
•Als PPTX, PDF herunterladen•
11 gefällt mir•3,034 views
It describes how to model microservices using domain driven design
Empfohlen
Weitere ähnliche Inhalte
Was ist angesagt?
Was ist angesagt? (20)
Ähnlich wie Modeling microservices using DDD
Ähnlich wie Modeling microservices using DDD (20)
Mehr von Masashi Narumoto
Kürzlich hochgeladen
Kürzlich hochgeladen (20)
Modeling microservices using DDD
- 1. Masashi Narumoto Principal PM Lead AzureCAT patterns&practices Modeling microservices using Domain Driven Design
- 2. Modeling microservices • How can I identify services? • How can I find service boundaries? • What is the right level of granularity? • How do I manage workflow? • How do I design inter-service communication? • How can I manage service dependency?
- 4. Domain Driven Design • Approach to design software by modeling the business domain • Strategic modeling • Ubiquitous language • Domain • Bounded context • Context mapping • Tactical modeling • Model inside bounded context • Building block patterns • Architecture • Hexagonal, Layers, CQRS, Microservices
- 5. When to use DDD? Source: Pattern of Enterprise Application Architecture: Martin Fowler
- 6. Rough sketch of drone delivery domain
- 7. Drone management Drone sharing 3rd party transportation Shipping (Core) Call center Accounts Drone management 3rd party transportation Call center Video surveillance Drone sharing Shipping Domain model Surveillance Accounts
- 8. Context map – managing dependencies • Tightly vs. Loosely coupled mapping patterns • Shared kernel, Partnership, Conformist, Customer-supplier, Big Ball of Mud • Anti-corruption layer, Separate ways, Open host service, Published language Shared assets Code Data model Infrastructure Bounded context A Bounded context B Shared kernel pattern Shared assets
- 9. Tactical modeling – Building blocks • Value object • Entity • Aggregate • Domain event • Domain Service • Application Service • Repository • Factory
- 10. Value object • Immutable object w/ business logic • Benefits • API clarity • In-place validation • Error handling • Data handling • Testability • Used as API parameters, events, identity, etc. • Example: email address, phone number Power use of value objects in DDD by Dan Bergh Johnsson
- 11. Entity • Has identity and lifecycle (not immutable) • Attributes and behavior • Can hold reference to other entities • Track changes using domain event (Event sourcing) • Example: User, Product
- 12. Aggregates • Group of entities and value objects • Defines consistency boundary • Keep invariants in consistency boundary • Modify one aggregate per transaction • Size • Large aggregate causes R/W overhead and more chance for optimistic CC to fail • Split a large aggregate to multiple smaller ones • Smaller ones perform/scale better • Too small aggregates causes invariants to be fragmented in multiple aggregates • Relationship • Reference other aggregates by ID • Example: User account, Subscription
- 13. Domain events • Events in business process • Events could be • Result of commands on Aggregates • Others • Event sourcing to store the history of events • Pub-Sub to notify multiple consumers • Example: Order placed, Delivery completed
- 14. Domain services • Stateless operations across multiple aggregates • Implement business logic • Significant business process • Transform domain object from one composition to another • Calculate a value with inputs from multiple domain objects • Don’t overuse services • Example: Delivery scheduling process
- 15. Application Service • Client of the domain service • No business logic • Typical tasks • Task coordination of use case flow • Assemble and send DTO over the wire • Create view model as resources in RESTful interface • Ensure ACID transactions • User authentication • Keep application service thin • Example: User authentication, Transferring DTO
- 16. Identify Microservices Aggregates Domainservices Reference Applicationservices DTO Aggregates Events Aggregates Root entity Other entities Value object
- 17. Identify Microservices Drone Scheduler Drone ID Req Delivery History Delivery Events Delivery Gateway Status ADLS Cosmos Cassandra
- 18. Identify Microservices Drone Scheduler Drone ID Req Delivery History Delivery Events Delivery Gateway Status Drone Delegating to remote service Other bounded context
- 20. User interface Applicationservices Aggregates Aggregates Events Applicationservices& Infrastructure DTO Application services & Infrastructure Identity provider Remote services Application services & Infrastructure Domainservices
- 21. Find service boundary • Bounded context is the service boundary • BC is a linguistic boundary • Analyze building blocks • Aggregate, Domain Service, App Service are good candidates for microservices • Break down further per each service characteristics • Lifecycle (Rate of change) • Quality attributes • Technology used • Team
- 22. Verify service granularity • Responsibility • Single responsibility • Lifecycle • Sharing the fate • Team size • 2 pizza rule • Dependency • No chatty calls between services • Other metrics • KPI such as velocity, team productivity, management cost etc. • Too small granularity causes issues • Communication overhead • Tight coupling • Lock-step deployment • Data consistency
- 23. Designing services for drone delivery
- 24. Process of designing microservices using DDD Accounts Drone management 3rd party transportation Call center Video surveillance Drone sharing Drone management Drone sharing 3rd party transportation Shipping (Core) Call center Shipping Surveillance Accounts Bounded context Aggregate Aggregate Aggregate Domain Service Domain ServiceAggregate Application Service Aggregate Event Domain model Domain building blocks Service mapping Shipping Drone Package Delivery DeliveryScheduler DeliverySupervisor Account 3rd party transportation Authentication Service in BC Service in BC Service In BC Service In BC Service outside Service outside Service outside Service outside Further refinement Breakdown per BC Service interaction design DeliveryScheduler Package Drone Delivery Mobile app Query Delivery History DeliveryEvents RequestEvents GW Status 3rd party Service Account Service DroneMgmt Service AAD Account Service Auth Service 3rd party transportation Account RequestHandler Delivery Analysis Archive Supervisor Failed ops Drone events
- 25. Ubiquitous language to model each domain
- 26. Drone management Drone sharing 3rd party transportation Shipping (Core) Call center Accounts Drone management 3rd party transportation Call center Video surveillance Drone sharing Shipping Context map – Drone delivery service Surveillance Accounts Shipping
- 27. Tactical patterns in shipping domain Shipping Drone History Delivery DeliveryScheduler DeliverySupervisor Account 3rd party transportation Authentication Aggregate Domain service Delivery event Event
- 28. Microservices in shipping domain Shipping Drone History Delivery DeliveryScheduler DeliverySupervisor Account 3rd party transportation Authentication DeliveryScheduler DeliverySupervisorHistory Authentication Drone Account 3rd party transportation Microservices Microservices In different BC Delivery event Delivery
- 29. Scheduler Package Drone Delivery Mobile app Query Delivery History DeliveryEvents RequestEvents GW Status 3rd party Service Account Service DroneMgmt Service Further breakdown AAD Account Service Auth Service 3rd party transportation Account Ingestion Delivery Analysis Archive Supervisor Failed ops Drone events Too much responsibility Different scalability Dealing with failure
- 30. Scheduler Package Drone Delivery Mobile app Query Delivery History RequestEvents GW Status 3rd party Service Account Service DroneMgmt Service Design patterns AAD Auth Service 3rd party transportation Account Ingestion Delivery Analysis Archive Supervisor Drone events Load levelingGW- routing Throttling Circuit breaker Bulkhead Sidecar GW- offloading Event sourcing Ambassador Materialized View Scheduler-agent-Supervisor
Hinweis der Redaktion
- Modeling software is a challenge. Modeling MSA is even harder. In modeling process, you need to answer these questions. Netflix runs 800 microservices. Uber runs 500. How can we find these services out on the drone delivery business? Changing boundaries are very expensive process.
- DDD can give you answers to all of these questions.
- In a nutshell, it’s an approach to design software by putting model as a center of the process. 2 different kinds of modeling, strategic and tactical. It can be applied to different kinds of architecture styles. A3G is a good place to learn these arch styles.
- Context map shows mapping among bounded context as well as domains and BC Domain represents problem space BC represents solution space
- Design time: Build, test, release If you expose language specific format or custom class/interface, it creates dependencies If you share data schema, library package, framework, etc. it creates dependencies If you share messaging infrastructure, storage it creates dependencies We should mitigate the area of shared kernel. Published language = Open API doc. You can mitigate the shared area by using nuget package etc.
- VO is immutable, there’s no history maintained. Can be used as parameter, event https://www.infoq.com/presentations/Value-Objects-Dan-Bergh-Johnsson Phone number Extract it out from an string argument Is it valid? Area code?
- P357: 70% of aggregates have one root entity + value object, 30% have 2 to 3 entities. Account = Admin + Members + Organization + Credit + Status
- Entities in aggregates have lifecycle. You may want to maintain the history of their status.
- DTO assembler to create DTO from domain object DTO is app specific, Value object is domain specific
- What’s the difference between microservices and their components? Should API layer a microservice?
- Team size = 2,3 upto 5,6 Lock-step deployment
- these are the considerations that you may going further down. Team size should be 2 to 6 guys. small teams make it easier to communicate more effectively rather than more, to stay decentralized and moving fast, and encourage high autonomy and innovation. http://blog.idonethis.com/two-pizza-team/ Too coarse grained causes dependency issues in build, release Too small grained causes overhead in communication, management, consistency It’s not like the more is the better.
- Easier said than done so we started our own project to show how to model service around business. Simply put, this service is to deliver good for you in a matter of minutes using drones.
- It doesn’t need to be mechanical translation by finding nouns, and verbs. It’s an iterative process to extract entities, service, aggregates, events etc.
- Context map shows mapping among bounded context as well as domains and BC Domain represents problem space BC represents solution space
- There’s no mechanical way to make decisions. Some aggregates deserve to be microservices, others don’t. Some aggregates should count on the ones in different BC. Responsibility of aggregates Delta Team size Dependency Latency
- How delivery service know its status? Is it coming from delivery mgmt service? (pull or push) Do we want to merge requestHandler and GW? GW does only token checking, delegate auth to auth service in account BC Why it has Package, Drone, Delivery as service but no service for account and 3rd party? Do we need them? Why doesn’t delivery service contain drone and package aggregate? Does drone need persistent storage or cache? What is the best API style? Depending on the responsibility and latency req of the drone service in this context, it can be just caching status Every event from drone come via EventHub to only DroneMgmt or + Delivery service? Scheduler does validation and return 501 (bad request) if it fails Account service subscribes delivery events and do the following once it’s completed Collect ratings, send emails, schedule payment
- How delivery service know its status? Is it coming from delivery mgmt service? (pull or push) Do we want to merge requestHandler and GW? GW does only token checking, delegate auth to auth service in account BC Why it has Package, Drone, Delivery as service but no service for account and 3rd party? Do we need them? Why doesn’t delivery service contain drone and package aggregate? Does drone need persistent storage or cache? What is the best API style? Depending on the responsibility and latency req of the drone service in this context, it can be just caching status Every event from drone come via EventHub to only DroneMgmt or + Delivery service? Scheduler does validation and return 501 (bad request) if it fails Account service subscribes delivery events and do the following once it’s completed Collect ratings, send emails, schedule payment