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.

Michael Plöd

May 14, 2018
Tweet

More Decks by Michael Plöd

Other Decks in Programming

Transcript

  1. 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).
  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 and ideas. If you haven’t: go out and get their amazing books!
  3. 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.
  4. 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
  5. 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
  6. 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
  7. 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
  8. 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
  9. Continuous Delivery is an important enabler for the agile, cultural

    part of DDD Business
 Domain
 Experts Developers
 Architects Operations
 DDD Dev
 Ops
  10. 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
  11. 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
  12. 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
  13. 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“.
  14. Upstream / Downstream Credit Agency Scoring Influence
 Flow Upstream System

    Downstream System Actions of the upstream team, have a
 direct impact on the downstream team.
  15. 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
  16. 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
  17. 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
  18. 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
  19. 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
  20. 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
  21. 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
  22. 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
  23. Shared Kernel Two teams share a subset of the domain

    model including code and maybe the database. Shared Kernel
  24. 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, ..)
  25. 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
  26. 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
  27. 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
  28. 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
  29. 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
  30. Aggregates (Internal) 
 Building Blocks Entities Value Objects Factories Services

    Repositories TACTICAL DESIGN helps us with regards to evolvability of microservices
  31. 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
  32. 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
  33. 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
  34. 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.
  35. 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.
  36. Entity Value Value Neither loose coupling, nor information hiding or

    cohesion are achieved with large object graphs
  37. 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)
  38. 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
  39. Credit
 Application
 Submitted Event We can use Domain Events for

    the communication between Microservices. This leads us to Event-driven Microservices
  40. An event is something 
 that happened in the past

    t now Event Event Event Event Event
  41. 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
  42. Command Aggregate Domain
 Event External 
 System Read
 Model Policy

    Command on on returns returns updates triggers invokes invokes
  43. 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
  44. Event Sourcing is an architectural pattern in which the state

    of the application is being determined by a sequence of events
  45. Using the ideas behind CQRS we can derive views that

    are optimized for queries from the event store
  46. !Never perform a big bang migration. Work in small steps

    and each step should deliver an improvement.
  47. 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).