Microservices love Domain-driven Design - Version 2

This is a new version of my talk about Microservices and DDD. It was first presented at the MicroCPH conference in Copenhagen, Denmark.

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 than ever.

This talk explains how the patterns and concepts of Domain Driven Design relate to Microservice architectures. We will see that Microservices are not only about Bounded Contexts and that there is much more to Domain Driven Design than Entities and Aggregates. In addition to that I will show 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). Finally, we will look into migrating existing monolithic applications with the help of patterns laid out in DDD.

Transcript

1. Microservices Domain-driven Design Michael Plöd, @bitboss <3
2. Check out my book https://leanpub.com/ddd-by-example This book aims to explain the concepts of Domain- driven Design in a way that it is easily applicable in practice. Each chapter contains a theoretical part which is explained from the point of view of practical applicability and then exercises with solutions based on a comprehensive, complex case study (real estate loans).
3. https://leanpub.com/ddd-by-example https://leanpub.com/ddd-referenz/
4. 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 and ideas. If you haven’t: go out and get their amazing books!
5. Feel free to replace developer by architect, team lead, team member or domain expert. Neither Domain-driven Design nor Microservices are silver bullets that solve all your problems just by applying them.
6. Domain-driven Design
 and
 Microservices a few disclaimers DDD and Microservices are not just about Bounded Contexts DDD itself is not just about Aggregates, Entities and Services
7. Domain-driven Design is not
 about technologies
8. Business
 Domain
 Experts Developers
 Architects D
 D D
9. Technical Language Business Language Business Folks Developers Domain Experts IT Folks Tracking 
 Postgres AI
 Engine Rabbit
 Messaging Results
 MySQL Parcel Sent Predict
 Delivery Recipient
 Notified
10. Technical Language Business Language Business Folks IT Folks Ubiquitous Language Domain Experts Developers
11. DOMAIN MODEL Domain Experts Developers Ubiquitous Language Conversations Code Drawings Documentation
12. Model your Microservices along business capabilities
13. Subdomains and Domain Models
14. Goal: independence of systems Not with a central domain model
15. Goal: independence of systems Design & Implementation Releasing & Deployment Runtime & Operations
16. Bounded Context Context Map Shared Kernel Customer / 
 Supplier Conformist Anticorruption
 Layer Separate W ays Open / Host 
 Service Published 
 Language STRATEGIC DESIGN helps us with regards to business capabilities
17. Bounded Context Every sophisticated business (sub-) domain consists of a bunch of Bounded Contexts Each Bounded Context contains a domain model, don’t nest Bounded Contexts The Bounded Context is also a boundary for the meaning of a given model
18. Example - You at Java Forum Stuttgart Reservations Event
 Management Badges Java Forum 
 Stuttgart
 Visitor Name Payment Details Address Company Session Registrations Lunch Preferences Name Job Description Twitter Handle
19. A Bounded Context is the 
 BOUNDARY
 for the meaning of a model
20. Don’t Repeat Yourself
21. Don’t Repeat Yourself INSIDE of a Bounded Context
22. Repeat Yourself BETWEEN several Bounded Contexts
23. Cut your
 Microservices 
 along Bounded Contexts
24. Don’t Repeat Yourself INSIDE of a Bounded Context Mic rose rvice
25. Repeat Yourself BETWEEN several Bounded Contexts Mic rose rvices You may want to
26. Mind Conway’s Law when dealing with communication between Microservices
27. Continuous Delivery is an important enabler for the agile, cultural part of DDD Business
 Domain
 Experts Developers
 Architects Operations
 DDD Dev
 Ops
28. DDD Software
 Engineering Domain
 Knowledge Agile
29. Communication between Contexts Call Flow How are calls and events flowing within a system / context landscape? Model Flow How do models propagate between systems? Where are boundaries? Influence Flow How do the actions of one team affect other teams? Who influences whom? or or Team Communication / Politics How do teams communicate with each other? Where are politics being played? or or
30. Eric Evans defined those seven 
 context mapping patterns Context Map Patterns by the books Shared Kernel Customer / Supplier Conformist Anticorruption Layer Separate Ways Open / Host Service Published Language
31. Vaughn Vernon added two more patterns to the list Context Map Patterns by the books Shared Kernel Customer / Supplier Conformist Anticorruption Layer Separate Ways Open / Host Service Published Language Partnership Big Ball Of Mud
32. Where should 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 relations 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“.
33. Upstream / Downstream Credit Agency Scoring Influence
 Flow Upstream System Downstream System Actions of the upstream team, have a
 direct impact on the downstream team.
34. Categories for 
 Context Mapping Patterns
35. Context Map Patterns Categorized Credit Agency Scoring Upstream-centric Patterns: • Open Host Service Downstream-centric Patterns: • Customer / Supplier • Conformist • Anticorruption Layer Bilateral Patterns: • Shared Kernel • Separate Ways • Published Language
36. Context Map Patterns Categorized Credit Agency Scoring Upstream-centric Patterns: • Open Host Service Downstream-centric Patterns: • Customer / Supplier • Conformist • Anticorruption Layer Bilateral Patterns: • Shared Kernel • Separate Ways • Published Language
37. Open Host Service 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. SOAP / REST for example
38. Context Map Patterns Categorized Credit Agency Scoring Upstream-centric Patterns: • Open Host Service Downstream-centric Patterns: • Customer / Supplier • Conformist • Anticorruption Layer Bilateral Patterns: • Shared Kernel • Separate Ways • Published Language
39. Customer / Supplier Upstream System Downstream System There is a customer / supplier relation ship between two teams. The down- stream team is considered to be the customer not having a full influence but has some influence. Downstream Team discusses model with Upstream Team
40. Conformist Upstream System Downstream System 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. The Downstream Team adapts to the model of the Upstream Team
41. Anticorruption Layer The anticorruption layer is a layer that isolates a client’s model from another system’s model by translation. External model to internal model transformation
42. Context Map Patterns Categorized Credit Agency Scoring Upstream-centric Patterns: • Open Host Service Downstream-centric Patterns: • Customer / Supplier • Conformist • Anticorruption Layer Bilateral Patterns: • Shared Kernel • Separate Ways • Published Language
43. Shared Kernel Two teams share a subset of the domain model including code and maybe the database. Shared Kernel
44. Separate Ways There is no connection between the bounded contexts of a system. This allows teams to find their own solutions in their domain. However there may be a „hidden“ connection between the teams. Look out of for „organizational“ Solutions (Excel, Access, ..)
45. 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. Typical examples are iCal or vCard. Implements according to Published Language Implements according to Published Language
46. Example: iCal The top-level element in iCalendar is the Calendaring and Scheduling Core Object, a collection of calendar and scheduling information. Typically, this information will consist of a single iCalendar object. However, multiple iCalendar objects can be grouped together. The first line must be BEGIN:VCALENDAR, and the last line must be END:VCALENDAR; the contents between these lines is called the "icalbody".
 The second line VERSION:2.0 indicates that the data is in iCalendar format. VERSION:1.0 was used to specify that data is in the old vCalendar format. The body of the iCalendar object (the icalbody) is made up of a list of calendar properties and one or more calendar components. The calendar properties apply to the entire calendar. The calendar components are several calendar properties which create a calendar schematic (design). For example, the calendar component can specify an event, a to-do list, a journal entry, time zone information, or free/busy time information, or an alarm. Empty lines are not allowed in some versions of usage (Google calendar). Source: https://en.wikipedia.org/wiki/ICalendar
47. Example: vCard vCard, also known as VCF (Virtual Contact File), is a file format standard for electronic business cards. vCards are often attached to e-mail messages, but can be exchanged in other ways, such as Multimedia Messaging Service(MMS), on the World Wide Web, instant messaging or through QR code. They can contain name and address information, telephone numbers, e-mail addresses, URLs, logos, photographs, and audio clips. vCard is used as data interchange format in personal digital assistants (PDAs), personal information managers (PIMs) and customer relationship management (CRMs). To accomplish these data interchange applications, other "vCard variants" have been used and proposed as "variant standards", each for its specific niche: XML representation, JSON representation, or web pages. Source: https://en.wikipedia.org/wiki/VCard
48. Context Maps and Conway’s Law Team independence Tight Coupling / Integration Shared Kernel Customer / Supplier Conformist Anticorruption Layer Separate Ways Open / Host Service Published Language Team Communication
49. U D D U U D Example: Context Maps Credit
 Application Scoring Credit
 Agency Customer Customer
 Contact O
 H
 S C
 F S K SUP ACL OHS C U
 S
50. Microservice architectures should be evolvable
51. Aggregates (Internal) 
 Building Blocks Entities Value Objects Factories Services Repositories TACTICAL DESIGN helps us with regards to evolvability of microservices
52. 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
53. 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
54. 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
55. Value Objects Expressiveness Value Objects add expressive names to key concepts in a model and increase the conceptual cohesiveness of objects. Focus for Entities Value Objects allow entities to focus on identity by delegating behavioral logic to them. Domain Concepts Value Objects enable moving from using primitives for simple domain concepts like postcode of an address.
56. Entity Value Value Using only Entities and Value Objects you will end up with big object graphs
57. Issues related to big object graphs Issues Navigation Endless navigation possibilities lead to less understandable code and is harder to maintain. Mind the „Law Of Demeter“. Consistency Big object graphs usually lead to large transactional boundaries and to a „everything must be consistent right now“ attitude. Cascading of errors The bigger the object graph, the easier it is for bugs to propagate or to pop up at places no one would expect. Testing Big and growing object graphs are hard to test. Sooner or later you end up with a ton of mocks.
58. Loose Coupling + Information Hiding + Cohesion Lets talk about
59. Entity Value Value Neither loose coupling, nor information hiding or cohesion are achieved with large object graphs
60. Building
 Blocks Aggregates Do not underestimate the power of the Aggregate
61. Aggregates group Entities and Value Objects
62. ROOT ROOT ROOT ROOT Each Aggregate has a Root Entity, aka Aggregate Root
63. Aggregates Domain Concepts Aggregates represent higher level business concepts. Behavior Try moving behavior to Value Objects in the Aggregates. The Entities should deal with lifecycle and identitiy. Invariants Aggregates allow us to implement and enforce rules and invariants (a fincancial situation must have in- and outgoings)
64. Connascence „In software engineering, two components are connascent if a change in one would require the other to be modified in order to maintain the overall correctness of the system.“ https://en.wikipedia.org/wiki/Connascence
65. Mind Microservice integration styles
66. Orchestration vs Choreography Building Microservices by Sam Newman, O'Reilly Event Stream Choreography Orchestration
67. Choreography Credit
 Application Scoring Credit Decision Customer Credit
 Application
 Submitted Event
68. Credit
 Application
 Submitted Event We can use Domain Events for the communication between Microservices. This leads us to Event-driven Microservices
69. ! Model information about activity in the domain as a series of discrete events.
70. An event is something 
 that happened in the past t now Event Event Event Event Event
71. How do I identify events?
72. Event Storming !
73. Invite the right people Provide unlimited 
 modelling space Explore the domain starting 
 from Domain Events Explore the the origins of Domain Events Look for Aggregates Source: http://ziobrando.blogspot.de/2013/11/introducing-event-storming.html Avoid tables / chairs
 in the room
74. Command Aggregate Domain
 Event External 
 System Read
 Model Policy Command on on returns returns updates triggers invokes invokes
75. REST + Events
 =
 Feeds
76. Application Approved Event Credit Decision The Credit Decision Microservice publishes the Application Approved Events as an Atom Feed via HTTP Contract Offers The Contract Offers Microservice polls the HTTP based Atom Feed at a predefined rate
77. In order to offer Feeds we must? Persist our Domain Events!
78. Event Sourcing is an architectural pattern in which the state of the application is being determined by a sequence of events
79. Using the ideas behind CQRS we can derive views that are optimized for queries from the event store
80. Migrating from monoliths to Microservices
81. Starting point: The monolith from the gates of hell
82. Bounded Contexts Top Down Context Maps Bottom Up Aggregates Microservice Candidates
83. !Never perform a big bang migration. Work in small steps and each step should deliver an improvement.
84. Microservices Domain-driven Design Michael Plöd, @bitboss <3
85. Check out my book https://leanpub.com/ddd-by-example This book aims to explain the concepts of Domain- driven Design in a way that it is easily applicable in practice. Each chapter contains a theoretical part which is explained from the point of view of practical applicability and then exercises with solutions based on a comprehensive, complex case study (real estate loans).