Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Microservices love Domain-driven Design - Version 2

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.

21a532a137b506128914478ac521fc8b?s=128

Michael Plöd

May 14, 2018
Tweet

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).