Microservices Domain-driven Design Michael Plöd, @bitboss <3

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

https://leanpub.com/ddd-by-example https://leanpub.com/ddd-referenz/

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!

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.

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

Domain-driven Design is not
 about technologies

Business
 Domain
 Experts Developers
 Architects D
 D D

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

Technical Language Business Language Business Folks IT Folks Ubiquitous Language Domain Experts Developers

DOMAIN MODEL Domain Experts Developers Ubiquitous Language Conversations Code Drawings Documentation

Model your Microservices along business capabilities

Subdomains and Domain Models

Goal: independence of systems Not with a central domain model

Goal: independence of systems Design & Implementation Releasing & Deployment Runtime & Operations

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

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

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

A Bounded Context is the 
 BOUNDARY
 for the meaning of a model

Don’t Repeat Yourself

Don’t Repeat Yourself INSIDE of a Bounded Context

Repeat Yourself BETWEEN several Bounded Contexts

Cut your
 Microservices 
 along Bounded Contexts

Don’t Repeat Yourself INSIDE of a Bounded Context Mic rose rvice

Repeat Yourself BETWEEN several Bounded Contexts Mic rose rvices You may want to

Mind Conway’s Law when dealing with communication between Microservices

Continuous Delivery is an important enabler for the agile, cultural part of DDD Business
 Domain
 Experts Developers
 Architects Operations
 DDD Dev
 Ops

DDD Software
 Engineering Domain
 Knowledge Agile

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

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

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

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

Upstream / Downstream Credit Agency Scoring Influence
 Flow Upstream System Downstream System Actions of the upstream team, have a
 direct impact on the downstream team.

Categories for 
 Context Mapping Patterns

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

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

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

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

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

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

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

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

Shared Kernel Two teams share a subset of the domain model including code and maybe the database. Shared Kernel

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

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

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

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

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

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

Microservice architectures should be evolvable

Aggregates (Internal) 
 Building Blocks Entities Value Objects Factories Services Repositories TACTICAL DESIGN helps us with regards to evolvability of microservices

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

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

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

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.

Entity Value Value Using only Entities and Value Objects you will end up with big object graphs

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.

Loose Coupling + Information Hiding + Cohesion Lets talk about

Entity Value Value Neither loose coupling, nor information hiding or cohesion are achieved with large object graphs

Building
 Blocks Aggregates Do not underestimate the power of the Aggregate

Aggregates group Entities and Value Objects

ROOT ROOT ROOT ROOT Each Aggregate has a Root Entity, aka Aggregate Root

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)

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

Mind Microservice integration styles

Orchestration vs Choreography Building Microservices by Sam Newman, O'Reilly Event Stream Choreography Orchestration

Choreography Credit
 Application Scoring Credit Decision Customer Credit
 Application
 Submitted Event

Credit
 Application
 Submitted Event We can use Domain Events for the communication between Microservices. This leads us to Event-driven Microservices

! Model information about activity in the domain as a series of discrete events.

An event is something 
 that happened in the past t now Event Event Event Event Event

How do I identify events?

Event Storming !

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

Command Aggregate Domain
 Event External 
 System Read
 Model Policy Command on on returns returns updates triggers invokes invokes

REST + Events
 =
 Feeds

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

In order to offer Feeds we must? Persist our Domain Events!

Event Sourcing is an architectural pattern in which the state of the application is being determined by a sequence of events

Using the ideas behind CQRS we can derive views that are optimized for queries from the event store

Migrating from monoliths to Microservices

Starting point: The monolith from the gates of hell

Bounded Contexts Top Down Context Maps Bottom Up Aggregates Microservice Candidates

!Never perform a big bang migration. Work in small steps and each step should deliver an improvement.

Microservices Domain-driven Design Michael Plöd, @bitboss <3

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