From a legacy monolith to microservices with Domain-driven Design

Slide 1

Slide 1 text

From a legacy monolith to microservices with Domain-driven Design Michael Plöd, @bitboss Mainz, 25. April 2018  JAX 2018

Slide 2

Slide 2 text

@bitboss Michael Plöd  Principal Consultant at INNOQ Deutschland GmbH • Interested in Software Architecture and Domain-driven Design • Twitter: @bitboss

Slide 3

Slide 3 text

!A monolith per se may not be a bad thing at all

Slide 4

Slide 4 text

No content

Slide 5

Slide 5 text

!Domain-driven Design is no silver bullet, it won’t heal everything, it’s just one set of tools among others.

Slide 6

Slide 6 text

Starting point: The monolith from the gates of hell

Slide 7

Slide 7 text

„There is this one critical team member that knows it inside out“ „Woha, how could that bug pop up after we changed something at a different place?“ „We can only do integration tests, unit tests are hard to write and are not present“ „Every year the price per feature raises and so do the number of bugs in production“

Slide 8

Slide 8 text

Let’s transform this beast to Microservices

Slide 9

Slide 9 text

Bounded Context Context Map Shared Kernel Customer /   Supplier Conformist Anticorruption  Layer Separate Ways Open / Host   Service Published   Language Aggregates Entities Value Objects Factories Services Repositories D D D

Slide 10

Slide 10 text

Bounded Context Every sophisticated business (sub-) 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 11

Slide 11 text

Example 1 - You at JAX Reservations Event  Management Badges JAX Visitor Name Payment Details Address Company Session Registrations Lunch Preferences Name Job Description Twitter Handle

Slide 12

Slide 12 text

Bounded Contexts Top Down Context Maps Bottom Up Aggregates Microservice Candidates

Slide 13

Slide 13 text

!Hint 1: manage expectations Often a full transformation to microservices will never happen. My mid-term priority would be to get to clean Bounded Contexts. After that I would consider microservices

Slide 14

Slide 14 text

Ask the right questions Goal What are the goals you want to achieve by decomposing your monolith? Type What type of monolith are you dealing with? Interactions If you have modules, how are they related to each other in terms of loose coupling? Modules Which vertical / business driven modules are roughly present?

Slide 15

Slide 15 text

! Hint 2: quality criteria Perform an early assessment of the real quality criteria that are relevant for your application

Slide 16

Slide 16 text

Perform a quality grooming workshop

Slide 17

Slide 17 text

Types of monoliths Sort of structured Big Ball Of Mud

Slide 18

Slide 18 text

Sort of structured monolith Not just horizontal but also some vertical slices / modules / components Still a lot of cross references between those verticals

Slide 19

Slide 19 text

Possible approach Steps 1 Try drawing a context map of your monoliths. Use the currently present vertical slices as a starting point and match the patterns on them 4 Start with one of the 2-3 migration steps by either pulling out a microservice or by refactoring towards a better internal structure 3 Match the ﬁndings of the previous steps with your migration goals and chose 2-3 initial migration steps 2 Identify hot spots and possible quick wins based on the context maps

Slide 20

Slide 20 text

Big Ball Of Mud monolith Some kind of horizontal layering but no vertical slices / modules Unstructured cross referencing. Everything can and does reference anything else

Slide 21

Slide 21 text

Possible approach Steps 1 Drawing a context map as a starter will hardly work here. So you should come up with a short list of „business module wise“ pain points 4 Start pulling out bounded contexts with aggregates towards microservices 3 After having introduced aggregates you may introduce bounded contexts as a next step. Still in the monolith 2 Refactor to aggregates, step by step. Move away from the procedural service driven anemic domain model. Don’t think about microservices at this stage.

Slide 22

Slide 22 text

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

Slide 23

Slide 23 text

Top Down Bottom Up Bounded Contexts Context Maps Aggregates

Slide 24

Slide 24 text

Context Map 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 25

Slide 25 text

Context Map Patterns by the books Shared Kernel Customer / Supplier Conformist Anticorruption Layer Separate Ways Open / Host Service Published Language Eric Evans defined those seven context mapping patterns and did not organize them any further. Also Vaughn Vernon stuck to this way of describing them. However we will classify them in: • Upstream Patterns • Downstream Patterns • In-Between Patterns In addition to that we will introduce an eighth pattern.

Slide 26

Slide 26 text

Upstream / Downstream Credit Agency Scoring Call Flow Model Flow Focus of   Context Map Upstream System Downstream System

Slide 27

Slide 27 text

Context Map Patterns Categorized Credit Agency Scoring Model Flow Upstream System Downstream System Upstream Patterns: • Open Host Service Downstream Patterns: • Customer / Supplier • Conformist • Anticorruption Layer In-Between Patterns: • Shared Kernel • Published Language • Separate Ways

Slide 28

Slide 28 text

Slide 29

Slide 29 text

Open Host Service Upstream System Downstream System Each Bounded Context offers a deﬁned 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

Slide 30

Slide 30 text

Idea: Event Publisher Upstream System Downstream System A Bounded Context publishes Domain Events. This can be done by messaging or feeds. Other Bounded Contexts may subscribe to those events in order react upon them. This is a new pattern, which is not part of the DDD books by Eric Evans or Vaughn Vernon publishes

Slide 31

Slide 31 text

Slide 32

Slide 32 text

Customer / Supplier Upstream System Downstream System There is a customer / supplier relation ship between two teams. The downstream team is considered to be the customer, sometimes with veto rights. Downstream Team discusses model with Upstream Team

Slide 33

Slide 33 text

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

Slide 34

Slide 34 text

Anticorruption Layer Upstream System Downstream System 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

Slide 35

Slide 35 text

Slide 36

Slide 36 text

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

Slide 37

Slide 37 text

Published Language Upstream System Downstream System 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. A typical example is the ISBN in the book publishing domain Implements according to Published Language Implements according to Published Language

Slide 38

Slide 38 text

Separate Ways There is no connection between the bounded contexts of a system. This allows teams to ﬁnd their own solutions in their domain. However there may be a „hidden“ connection between the teams. Look out of for „organizational“ Solutions (Excel, Access, ..)

Slide 39

Slide 39 text

Slide 40

Slide 40 text

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 Event Publisher

Slide 41

Slide 41 text

Example: Context Maps https://github.com/mploed/ddd-strategic-design-spring-boot https://github.com/mploed/ddd-strategic-design-spring-boot

Slide 42

Slide 42 text

U D D D U U U U D D Example: Context Maps Credit  Application Scoring Credit  Agency Customer Customer  Contact O  H  S OHS C  F S K CF E  P A  C  L ACL EP

Slide 43

Slide 43 text

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

Slide 44

Slide 44 text

Top Down Bottom Up Bounded Contexts Context Maps Aggregates

Slide 45

Slide 45 text

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

Slide 46

Slide 46 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 47

Slide 47 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 48

Slide 48 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 49

Slide 49 text

Building  Blocks Aggregates Do not underestimate the power of the Aggregate

Slide 50

Slide 50 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 51

Slide 51 text

Building  Blocks Aggregates SelfDisclosure Address RedemptionDetail Loan Customer LoanApplicationForm Take a look at this approach which is more ﬁne grained

Slide 52

Slide 52 text

Best Practices for Aggregates Hints Small Prefer small aggregates that usually only contain an Entity and some Value Objects. Consistency Boundaries Take a look which parts of your model must be updated in an atomically consistent manner One TX per Aggregate Aggregates should be updated in separate transations which leads to eventual consistency Reference by Identity Do not implement direct references to other Root Entities. Prefer referencing to Identity Value Objects

Slide 53

Slide 53 text

Building  Blocks Aggregate Example Battery of an electric car Battery Cells Status Charger Cell Cell Cell Cell Cell Cell Cell Cell Cell Cell Cell Cell Cell Cell Cell Cell Cell Cell Cell Cell Cell Cell Cell Cell Cell Cell Cell Cell Cell Cell Cell Cell Cell Cell Cell Cell General Information

Slide 54

Slide 54 text

Building  Blocks Aggregate Example Battery of an electric car Think about good a good old OO practice: information hiding Personal opionion: In the advent of POJOs we have unlearned information hiding A blind „Genereate Getters and Setters“ in your IDE is your enemy Battery Cells Status Charger Cell Cell Cell Cell Cell Cell Cell Cell Cell Cell Cell Cell Cell Cell Cell Cell Cell Cell Cell Cell Cell Cell Cell Cell Cell Cell Cell Cell Cell Cell Cell Cell Cell Cell Cell Cell General Information

Slide 55

Slide 55 text

Building  Blocks Aggregate Example Battery of an electric car Do we need an external access to the cells? Stuff we want to do from the outside: - Start charging - Get current charge level - Get information about the charging Battery Cells Status Charger Cell Cell Cell Cell Cell Cell Cell Cell Cell Cell Cell Cell Cell Cell Cell Cell Cell Cell Cell Cell Cell Cell Cell Cell Cell Cell Cell Cell Cell Cell Cell Cell Cell Cell Cell Cell General Information

Slide 56

Slide 56 text

Let’s look at some aggregates

Slide 57

Slide 57 text

Bounded Contexts Top Down Context Maps Bottom Up Aggregates Microservice Candidates

Slide 58

Slide 58 text

> https://leanpub.com/ddd-by-example > Follow me on Twitter: @bitboss Thank you very much!