Slide 1

Slide 1 text

Microservices <3 Domain Driven Design Michael Plöd - innoQ
 @bitboss

Slide 2

Slide 2 text

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!

Slide 3

Slide 3 text

D D D in Microservices DDD and Microservices are not just about Bounded Contexts DDD itself is not just about Aggregates, Entities and Services

Slide 4

Slide 4 text

Domain Driven Design helps us with
 Microservices in four areas Strategic Design (Internal) 
 Building Blocks Large Scale
 Structure Destillation

Slide 5

Slide 5 text

Strategic Design Strategic Design consists of Bounded Context Context Map Shared Kernel Customer / 
 Supplier Conformist Anticorruption
 Layer Separate Ways Open / Host 
 Service Published 
 Language

Slide 6

Slide 6 text

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

Slide 7

Slide 7 text

Strategic
 Design Bounded Context Example Reservations Event
 Management Badges Customer Name Payment Details Address Company Session Registrations Lunch Preferences Name Job Description Twitter Handle

Slide 8

Slide 8 text

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?

Slide 9

Slide 9 text

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

Slide 10

Slide 10 text

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.

Slide 11

Slide 11 text

Strategic Design Strategic Design consists of Bounded Context Context Map Shared Kernel Customer / 
 Supplier Conformist Anticorruption
 Layer Separate Ways Open / Host 
 Service Published 
 Language

Slide 12

Slide 12 text

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

Slide 13

Slide 13 text

Strategic
 Design Context Map - Patterns Shared Kernel Customer / 
 Supplier Conformist Anticorruption
 Layer Separate Ways Open / Host 
 Service Published 
 Language

Slide 14

Slide 14 text

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.

Slide 15

Slide 15 text

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.

Slide 16

Slide 16 text

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.

Slide 17

Slide 17 text

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.

Slide 18

Slide 18 text

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.

Slide 19

Slide 19 text

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.

Slide 20

Slide 20 text

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.

Slide 21

Slide 21 text

Strategic
 Design Context Map - Why? Credit
 Application Credit
 Decision Scoring Credit
 Agency CRM

Slide 22

Slide 22 text

Strategic
 Design Context Map - Why? Credit
 Application Credit
 Decision Scoring Credit
 Agency CRM Currently we only see call stacks

Slide 23

Slide 23 text

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

Slide 24

Slide 24 text

Strategic
 Design and Conway’s Law Shared Kernel Customer / Supplier Conformist Anticorruption Layer Separate Ways Open / Host Service Published Language

Slide 25

Slide 25 text

Strategic
 Design and Conway’s Law Shared Kernel Customer / Supplier Conformist Anticorruption Layer Separate Ways Open / Host Service Published Language Team Communication

Slide 26

Slide 26 text

Strategic
 Design and Conway’s Law Shared Kernel Customer / Supplier Conformist Anticorruption Layer Separate Ways Open / Host Service Published Language Team Communication

Slide 27

Slide 27 text

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

Slide 28

Slide 28 text

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

Slide 29

Slide 29 text

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

Slide 30

Slide 30 text

Strategic
 Design Where do Context Maps help?

Slide 31

Slide 31 text

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

Slide 32

Slide 32 text

Domain Driven Design helps us with
 Microservices in four areas Strategic Design (Internal) 
 Building Blocks Large Scale
 Structure Destillation

Slide 33

Slide 33 text

Building Blocks help designing 
 the internals of
 Bounded Contexts Aggregates (Internal) 
 Building Blocks Entities Value Objects Factories Services Repositories

Slide 34

Slide 34 text

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

Slide 35

Slide 35 text

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

Slide 36

Slide 36 text

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

Slide 37

Slide 37 text

Building
 Blocks Aggregates Do not underestimate the power of the Aggregate

Slide 38

Slide 38 text

Building
 Blocks Aggregates SelfDisclosure Address RedemptionDetail Loan Customer LoanApplicationForm Aggregates group Entities. The Root Entity is the lead in terms of access to the object graph and lifecycle.

Slide 39

Slide 39 text

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

Slide 40

Slide 40 text

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

Slide 41

Slide 41 text

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!

Slide 42

Slide 42 text

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

Slide 43

Slide 43 text

„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?

Slide 44

Slide 44 text

! Domain Events are something that happened that Domain Experts care about

Slide 45

Slide 45 text

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

Slide 46

Slide 46 text

Triggers of Events Documents Time Applications User Actions

Slide 47

Slide 47 text

Loan Details Entered Financial Situation Entered Personal Infromation Entered Application Submitted Credit
 Application Scoring Credit
 Decision Customer

Slide 48

Slide 48 text

Domain Driven Design helps us with
 Microservices in four areas Strategic Design (Internal) 
 Building Blocks Large Scale
 Structure Destillation

Slide 49

Slide 49 text

Large Scale Structure helps evolving our Microservice landscapes Evolving
 Order Large Scale
 Structure System
 Metaphor Resposibility
 Layers

Slide 50

Slide 50 text

Large
 Scale
 Structure Evolving Order

Slide 51

Slide 51 text

Large
 Scale
 Structure Evolving Order Job Title: 
 Chief Ivory Tower Architect

Slide 52

Slide 52 text

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“

Slide 53

Slide 53 text

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

Slide 54

Slide 54 text

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

Slide 55

Slide 55 text

Large
 Scale
 Structure Responsibility Layers Registration Event
 Management Badges Mailings Speakers

Slide 56

Slide 56 text

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

Slide 57

Slide 57 text

Domain Driven Design helps us with
 Microservices in four areas Strategic Design (Internal) 
 Building Blocks Large Scale
 Structure Destillation

Slide 58

Slide 58 text

Destillation helps extracting Microservices out of an existing monolithic application Destillation

Slide 59

Slide 59 text

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

Slide 60

Slide 60 text

Destilla-
 tion Extract subdomains Identification of subdomain Extraction from core Clean separation Internal refactoring

Slide 61

Slide 61 text

Microservices Domain Driven Design Strategic Design (Internal) 
 Building Blocks Large Scale
 Structure Destillation <3

Slide 62

Slide 62 text

THANK YOU! <3 Michael Plöd - innoQ
 @bitboss Shameless plug: we offer DDD trainings and consulting