Microservices love Domain Driven Design, why and how?

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 speciﬁc context. Also think about decoupling of models.

Slide 11

Slide 11 text

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

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

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 Inﬂexible 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 ﬁt 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 Deﬁnes what is in the core domain and what is not in the core domain

Slide 60

Slide 60 text

Destilla-  tion Extract subdomains Identiﬁcation 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