Microservices love Domain Driven Design, why and how?

Without any doubt Eric Evans' book "Domain Driven Design" is being considered as a "must have read" among many IT specialists from various domains. With the emergence of Microservices Domain Driven Design has become more relevant then ever. This talk explains how the patterns and concepts of Domain Driven Design relate to Microservice architectures. In addition to that I will show off how Domain Driven Design will help you to structure and model your Microservices in terms of granularity, business context and interface design (just to name a few).

Transcript

1. Microservices <3 Domain Driven Design Michael Plöd - innoQ
 @bitboss
2. Disclaimer Michael Plöd - innoQ
 @bitboss Most of these ideas do not come from me personally. I have to thank Eric Evans and Vaughn Vernon for all the inspiration / ideas. If you haven’t: go out and get their amazing books!
3. D D D in Microservices DDD and Microservices are not just about Bounded Contexts DDD itself is not just about Aggregates, Entities and Services
4. Domain Driven Design helps us with
 Microservices in four areas Strategic Design (Internal) 
 Building Blocks Large Scale
 Structure Destillation
5. Strategic Design Strategic Design consists of Bounded Context Context Map Shared Kernel Customer / 
 Supplier Conformist Anticorruption
 Layer Separate Ways Open / Host 
 Service Published 
 Language
6. Strategic
 Design Bounded Context Every sophisticated business domain consists of a bunch 
 of Bounded Contexts Each Bounded Context contains models and maybe other contexts The Bounded Context is also a boundary for the meaning of a given model
7. Strategic
 Design Bounded Context Example Reservations Event
 Management Badges Customer Name Payment Details Address Company Session Registrations Lunch Preferences Name Job Description Twitter Handle
8. Strategic
 Design Bounded Context Example Reservations Event
 Management Badges Name Payment Details Adress Company Session Registrations Lunch Preferences Name Job Description Twitter Handle Each Bounded Context has its own model of a customer This is a major enabler for independent Microservices Take a look at the name of the customer? Maybe we want some shared data?
9. Strategic
 Design Bounded Context Example Personal
 Driving Service
 Center Car Think about the differences in starting the car or simple components such as ABS, ESP, engine or infotainment
10. Strategic
 Design How to identify Bounded
 ContextS? Factors One Team If a Bounded Context must be managed or imple- mented by more than one team it is probably too big and should be split up. Language Models act as an Ubiquitous Language, therefore it is necessary to draw a line between Contexts when the project langeuage changes. Cohesion Take a look at your (sub-) domain and think about which parts of that domain are strongly related or in other words highly cohesive. Meaningful Model Try to identify models that make sense and that are meaningful in one specific context. Also think about decoupling of models.
11. Strategic Design Strategic Design consists of Bounded Context Context Map Shared Kernel Customer / 
 Supplier Conformist Anticorruption
 Layer Separate Ways Open / Host 
 Service Published 
 Language
12. Context Map Strategic
 Design The Bounded Context by itself does not deliver an overview of the system By introducing a Context Map we describe the contact between models / contexts The Context Map is also a great starting point for future transformations
13. Strategic
 Design Context Map - Patterns Shared Kernel Customer / 
 Supplier Conformist Anticorruption
 Layer Separate Ways Open / Host 
 Service Published 
 Language
14. Strategic
 Design Context Map - Patterns Shared Kernel Customer / Supplier Conformist Anticorruption Layer Separate Ways Open / Host Service Published Language Two teams share a subset of the domain model including code and maybe the database. The shared kernel is often refered to as the core domain.
15. Strategic
 Design Context Map - Patterns Shared Kernel Customer / Supplier Conformist Anticorruption Layer Separate Ways Open / Host Service Published Language There is a customer / supplier relation ship between two teams. The downstream team is considered to be the customer, sometimes with veto rights.
16. Strategic
 Design Context Map - Patterns Shared Kernel Customer / Supplier Conformist Anticorruption Layer Separate Ways Open / Host Service Published Language The downstream team conforms to the model of the upstream team. There is no translation of models and no vetoing. If the upstream model is a mess, it propagates to the downstream model.
17. Strategic
 Design Context Map - Patterns Shared Kernel Customer / Supplier Conformist Anticorruption Layer Separate Ways Open / Host Service Published Language The anticorruption layer is a layer that isolates a client’s model from another system’s model by translation.
18. Strategic
 Design Context Map - Patterns Shared Kernel Customer / Supplier Conformist Anticorruption Layer Separate Ways Open / Host Service Published Language There is no connection between the bounded contexts of a system. This allows teams to find their own solutions in their domain.
19. Strategic
 Design Context Map - Patterns Shared Kernel Customer / Supplier Conformist Anticorruption Layer Separate Ways Open / Host Service Published Language Each Bounded Context offers a defined set of services that expose functionality for other systems. Any downstream system can then implement their own integration. This is especially useful for integration requirements with many other systems.
20. Strategic
 Design Context Map - Patterns Shared Kernel Customer / Supplier Conformist Anticorruption Layer Separate Ways Open / Host Service Published Language Published Language is quite similar to Open / Host Service. However it goes as far as to model a Domain as a common language between bounded contexts.
21. Strategic
 Design Context Map - Why? Credit
 Application Credit
 Decision Scoring Credit
 Agency CRM
22. Strategic
 Design Context Map - Why? Credit
 Application Credit
 Decision Scoring Credit
 Agency CRM Currently we only see call stacks
23. Strategic
 Design Context Map Credit
 Application Credit
 Decision Scoring Credit
 Agency CRM U D D D D U U U C
 F O
 H
 S C
 U
 S O
 H
 S O H S A C L S K S K
24. Strategic
 Design and Conway’s Law Shared Kernel Customer / Supplier Conformist Anticorruption Layer Separate Ways Open / Host Service Published Language
25. Strategic
 Design and Conway’s Law Shared Kernel Customer / Supplier Conformist Anticorruption Layer Separate Ways Open / Host Service Published Language Team Communication
26. Strategic
 Design and Conway’s Law Shared Kernel Customer / Supplier Conformist Anticorruption Layer Separate Ways Open / Host Service Published Language Team Communication
27. Tight Coupling / Integration Strategic
 Design and Conway’s Law Shared Kernel Customer / Supplier Conformist Anticorruption Layer Separate Ways Open / Host Service Published Language Team Communication
28. Tight Coupling / Integration Strategic
 Design and Conway’s Law Shared Kernel Customer / Supplier Conformist Anticorruption Layer Separate Ways Open / Host Service Published Language Team Communication
29. Team independence Tight Coupling / Integration Strategic
 Design and Conway’s Law Shared Kernel Customer / Supplier Conformist Anticorruption Layer Separate Ways Open / Host Service Published Language Team Communication
30. Strategic
 Design Where do Context Maps help?
31. Strategic
 Design Where do Context Maps help? Governance A Context Map helps to identify governance issues between applications and teams. Transformation A Context Map is an excellent starting point for future transformations: it gives an in-depth insight into integration aspects and subdomain / context mathesxw Bad Models By introducing a Context Map we get a clear view on where and how bad models propagate through application landscapes Politics By not just looking at technical integration aspects the Context Map also helps us in seeing how teams communicate and „play politics“.
32. Domain Driven Design helps us with
 Microservices in four areas Strategic Design (Internal) 
 Building Blocks Large Scale
 Structure Destillation
33. Building Blocks help designing 
 the internals of
 Bounded Contexts Aggregates (Internal) 
 Building Blocks Entities Value Objects Factories Services Repositories
34. Building
 Blocks Entities Entities represent the core business objects of a bounded context’s model Each Entity has a constant identity Each Entity has its own lifecycle Customer Credit Application Shipment
35. Building
 Blocks Value Objects Value Objects derive their identity from their values Value Objects do not have their own lifecycle, they inherit it from Entities that are referencing them You should always consider value objects for your domain model Color Monetary Amount Customer
36. Building
 Blocks Is „Customer“ an Entity or 
 a Value Object If an object can be considered an Entity or a Value Object always depends on the (Bounded Context) it resides in. Customer Example: A customer is an entity in a CRM-like microservice but not in a microservice that prints badges, there we are just interested in name, job description and Twitter handle
37. Building
 Blocks Aggregates Do not underestimate the power of the Aggregate
38. Building
 Blocks Aggregates <ValueObject> SelfDisclosure <ValueObject> Address <ValueObject> RedemptionDetail <Entity> Loan <Entity> Customer <Entity> LoanApplicationForm <Root Entity> <Root Entity> Aggregates group Entities. The Root Entity is the lead in terms of access to the object graph and lifecycle.
39. Building
 Blocks Factories, Services, 
 Repositories Aggregates Entities Value Objects Factories Services Repositories Factories take care of Entity- / Aggregate-Instantiations Repositories encapsulate and represent data access Services implement business logic that relates to multiple Entities / Aggreates
40. Building
 Blocks Align the internal building blocks
 along Application Services and the Domain Model Input Adapter Web Mobile Cloud Messaging Database Document GraphDB Messaging Output Adapter Application
 Service Domain
 Model Persistence Domain Events Domain Events
41. Building
 Blocks Align the internal building blocks
 along Application Services and the Domain Model Input Adapter Web Mobile Cloud Messaging Database Document GraphDB Messaging Output Adapter Application
 Service Domain
 Model Persistence Domain Events Domain Events I never heard of 
 DOMAIN EVENTS before!
42. „After inserting data into“ „We need to check the status of“ „When we have called System X“ „If that happens“ „After the customer has“ „Notify me if“ „When ..“
43. „After inserting data into“ „We need to check the status of“ „When we have called System X“ „If that happens“ „After the customer has“ „Notify me if“ „When ..“ Ubiquitous
 Language
 anyone?
44. ! Domain Events are something that happened that Domain Experts care about
45. ! Model information about activity in the domain as a series of discrete events.
46. Triggers of Events Documents Time Applications User Actions
47. Loan Details Entered Financial Situation Entered Personal Infromation Entered Application Submitted Credit
 Application Scoring Credit
 Decision Customer
48. Domain Driven Design helps us with
 Microservices in four areas Strategic Design (Internal) 
 Building Blocks Large Scale
 Structure Destillation
49. Large Scale Structure helps evolving our Microservice landscapes Evolving
 Order Large Scale
 Structure System
 Metaphor Resposibility
 Layers
50. Large
 Scale
 Structure Evolving Order
51. Large
 Scale
 Structure Evolving Order Job Title: 
 Chief Ivory Tower Architect
52. Large
 Scale
 Structure Evolving Order Job Title: 
 Chief Ivory Tower Architect Rigid Development Guidelines Inflexible Architecture
 
 Clear rules and conventions for everything „I don’t need expensive developers, I prefer cheap ones and I do the thinking for them“
53. Large
 Scale
 Structure Evolving Order Development Team System is too complex Let’s dumb down the system to fit the rules
 
 We need a workaround to undermine some rules
54. Sounds familiar in a microservice environment? Large
 Scale
 Structure Evolving Order Evolving
 Order Let large structures evolve, don’t overconstrain design principles These large structures should be applicable across bounded contexts However there should be some practical constraints
55. Large
 Scale
 Structure Responsibility Layers Registration Event
 Management Badges Mailings Speakers
56. Large
 Scale
 Structure Responsibility Layers Registration Event
 Management Badges Mailings Speakers Each of these Microservices is structures according to a bounded context Inside these context developers have the chance to use building blocks However we could structure our bounded context according to responsibilities
57. Domain Driven Design helps us with
 Microservices in four areas Strategic Design (Internal) 
 Building Blocks Large Scale
 Structure Destillation
58. Destillation helps extracting Microservices out of an existing monolithic application Destillation
59. Destilla-
 tion Identify the core domain Destillation Document Describes all the details of the core domain Vision Statement Defines what is in the core domain and what is not in the core domain
60. Destilla-
 tion Extract subdomains Identification of subdomain Extraction from core Clean separation Internal refactoring
61. Microservices Domain Driven Design Strategic Design (Internal) 
 Building Blocks Large Scale
 Structure Destillation <3
62. THANK YOU! <3 Michael Plöd - innoQ
 @bitboss Shameless plug: we offer DDD trainings and consulting