Domain-driven Design: A Complete Example

Slide 1

Slide 1 text

Domain-driven Design: A Complete Example Eberhard Wolff Head of Architecture https://swaglab.rocks/ https://ewolff.com/

Slide 2

Slide 2 text

Why This Talk? •Domain-driven Design provides lots of tools. •Which are really useful? •How can you combine them?

Slide 3

Slide 3 text

Note •This might look like a waterfall. •It is about different levels of abstractions. •Work in iterations! •Change the level of abstraction!

Slide 4

Slide 4 text

Event Storming

Slide 5

Slide 5 text

Why Event Storming? Domain Experts Understand the domain Software Engineers Structure knowledge to become software How does domain knowledge become software?

Slide 6

Slide 6 text

Why Event Storming? Domain Experts Don’t know formal methods Software Engineers Don’t know the domain How does domain knowledge become software?

Slide 7

Slide 7 text

Why Event Storming? Domain Experts Software Engineers Model

Slide 8

Slide 8 text

What is Event Storming? •Event in the past •At least noun + verb •Verb in past tense •Write event on orange sticky Order accepted

Slide 9

Slide 9 text

Phase: Chaotic Exploration •Create as many events as possible

Slide 10

Slide 10 text

Phase: Enforce the timeline

Slide 11

Slide 11 text

Phase: Enforce the timeline

Slide 12

Slide 12 text

Phase: Identify Swim Lanes •Parallel activities Swimlane Invoicing Swimlane Delivery

Slide 13

Slide 13 text

Phase: Identify Pivotal Events •Afterwards the world is different Order accepted Parcel left warehouse Swimlane Invoicing Swimlane Delivery

Slide 14

Slide 14 text

Event Storming: Benefits •Low-tech: easy to understand for domain experts •People can work in parallel. •Social structures become obvious.

Slide 15

Slide 15 text

Event Storming: Challenge •Get the right people •Actual users might not have the vision and context. •Managers might not understand problems in day-to- day work. •Everyone will only understand a part of the logic.

Slide 16

Slide 16 text

Event Storming: Result •Common understanding of the domain •A model of the domain …that must be tweaked before it can be implemented •Roles and collaboration in the project become obvious

Slide 17

Slide 17 text

Bounded Context

Slide 18

Slide 18 text

Why Bounded Context? •Coarse-grained split of the domain •A scope that might be assigned to a team •A team might work on multiple bounded contexts …but a bounded context should belong to one team.

Slide 19

Slide 19 text

Bounded Context Bounds Model i.e. Code Ubiquitous Language

Slide 20

Slide 20 text

Ubiquituous Language Database Code Software Engineers Domain Experts

Slide 21

Slide 21 text

Invoicing Process Bounded Context Example Customer who pays the bill Delivery Customer who the products are sent to

Slide 22

Slide 22 text

Parcel left warehouse Identify Candidates for Bounded Contexts •Areas between swim lanes and pivotal events are good candidates for Bounded Contexts •Not all pivotal events separate bounded contexts Swimlane Delivery Order accepted Swimlane Invoicing

Slide 23

Slide 23 text

Slide 24

Slide 24 text

Identify Candidates for Bounded Contexts •Reimbursements handled in invoicing? •Return handled in delivery process? •Is the model usable for both? Invoicing Delivery Process Order Processing

Slide 25

Slide 25 text

Bounded Context: Benefits •Structures domain logic •Request probably local to one bounded context •Changes probably local to one bounded context •i.e. a great architecture!

Slide 26

Slide 26 text

Bounded Context: Challenges •Legacy systems have different models. •Most people have an ad-hoc way to structure systems •Mind shift: Focus in domain logic •Mind shift: Functionality not data

Slide 27

Slide 27 text

Core Domain

Slide 28

Slide 28 text

Core Domain •Core domain = motivation for the project •Reduce the complexity of the model •Focus on maintainability of this part of the system

Slide 29

Slide 29 text

What is the Core Domain? •We delivery quickly and reliably •So: core domain = delivery process •Rest: generic subdomain …or supporting subdomain Invoicing Delivery Process Order Processing

Slide 30

Slide 30 text

Not Strategic Design but Team Topologies

Slide 31

Slide 31 text

Why Team Topologies? •Somehow teams need to collaborate •Not too complex •Intuitive (?) •Covers more “fracture planes” then just Bounded Contexts e.g. location •Covers more team types than development teams

Slide 32

Slide 32 text

Team Topologies Stream-aligned team Platform team Enabling team Complicated Subsystem team XaaS Collaboration Facilitating XaaS

Slide 33

Slide 33 text

Team Topologies Order Processing Kubernetes / CI Team Delivery Optimization Invoicing Delivery XaaS Architecture Collaboration Facilitating XaaS

Slide 34

Slide 34 text

Team Topologies: Challenges •Magnets i.e. a goal

Slide 35

Slide 35 text

https://software-architektur.tv/2024/04/18/folge213.html

Slide 36

Slide 36 text

Finally: Coding!

Slide 37

Slide 37 text

Finally: Coding! (sort of )

Slide 38

Slide 38 text

Tactical Design

Slide 39

Slide 39 text

Why Tactical Design? •Object-oriented concepts •Make a lot of sense to build good object-oriented systems!

Slide 40

Slide 40 text

Tactical Design Entity Value Object Domain Event Identity: a person Value: 2€, 2m Something has happened. Matters to domain experts

Slide 41

Slide 41 text

Tactical Design Entity Value Object Aggregate Factory Repository Domain Event Consists of Entities and Value Objects Aggregate Root ensures consistency Illusion of a collection of aggregates Creates complex value objects and aggregates

Slide 42

Slide 42 text

Tactical Design Entity Value Object Aggregate Factory Repository Service Domain Event Logic doesn‘t fit in Entities / Aggregates

Slide 43

Slide 43 text

Alternative: Functional Programming •Side-effect free functional core •i.e. no entities, aggregates etc •Side-effects separated

Slide 44

Slide 44 text

Alternatives for Less Complex Systems •Transaction script: handles a single request from the presentation incl. database code. •Table model: Single instance handles business logic for all rows in a database table or view.

Slide 45

Slide 45 text

Example: Delivery Bounded Context Parcel <> Adress <> Customer <> Delivery Factory Delivery Repository ScheduleDelivery <> DeliveryScheduled <> Delivery <>

Slide 46

Slide 46 text

https://software-architektur.tv/2024/05/03/folge214.html

Slide 47

Slide 47 text

Framework? •POJO (Plain Old Java Objects) might be enough •https://xmolecules.org/ supports DDD concepts •https://odrotbohm.de/2020/03/Implementing-DDD- Building-Blocks-in-Java/ describes the idea

Slide 48

Slide 48 text

Framework? •Might use architecture management tools to enforce dependencies •https://software-architektur.tv/ tags.html#Architecture%20Management

Slide 49

Slide 49 text

Design-Level Event Storming Actor Command System Domain Event External System Policy Command Read Model UI

Slide 50

Slide 50 text

Design-Level Event Storming •Helps to understand the domain on the necessary level of detail •But no easy mapping to tactical domain-driven design

Slide 51

Slide 51 text

Design-Level Event Storming Actor Command System Domain Event External System Policy Command Read Model UI Aggregate Aggregate, Service Aggregate, Service Aggregate, Service Domain Event

Slide 52

Slide 52 text

Event Sourcing •Store events that lead to a specific state •Might also store state (optional) •System of record: State or events

Slide 53

Slide 53 text

Interface Calls, messages, … Event Store Order Cancelled 42 Order Accepted 23 Order Accepted 42 Order 42 Order 23 Order Delivered 23 Order 23 State Order 42

Slide 54

Slide 54 text

State Events Calculate State on Demand State+ Events Event Sourcing

Slide 55

Slide 55 text

Event Sourcing Example Event Store Delivery loaded 42 Delivery picked up 42 Delivery scheduled 42 Delivery delivered 42 Delivery acknowledged 42 Can you model delivery without an event store? Why calculate the state of a delivery based on the events and not store the state?

Slide 56

Slide 56 text

CQRS •Command Query Responsibility Separation •E.g. separate read and write

Slide 57

Slide 57 text

Command Queue Command Command Command Command Handler Query Handler Command Store Database Read Invoice Payment Read Replica? Create Invoice! CQRS

Slide 58

Slide 58 text

Command Queue Command Command Command Command Handler Query Handler Command Store Snapshot Read Invoice Create Invoice! Payment Event Sourcing Might make sense for e.g. statistics CQRS

Slide 59

Slide 59 text

Command Queue Command Command Command Command Handler Query Handler Command Store Snapshot Read Invoice Create Invoice! Payment Event Sourcing Might make sense for e.g. statistics CQRS Can you model statistics differently? Statistics is probably a different bounded context. Why would you use CQRS for the rest?

Slide 60

Slide 60 text

Layers •Actually pattern in the original DDD book. •Separate logic •To isolate logic in one place •To make the system easier to understand Persistence Logic UI

Slide 61

Slide 61 text

Hexagonal •Business logic exports ports •Adapters implement ports •Logic isolated and easy to understand •Better testability Business Logic Persistence Business Event Notification Admin Database adapter EMail adapter Admin UI UI

Slide 62

Slide 62 text

Conclusion

Slide 63

Slide 63 text

Conclusion Big Picture Event Storming Bounded Context Core Domain Strategic Design? Team Topologies More details Event Sourcing? CQRS? Layers? Hexagonal? Design-level Event Storming Tactical Design

Slide 64

Slide 64 text

Send email to [email protected] Slides + Sample Microservices Book DE / EN + Sample Practical Microservices DE/EN + Sample of Continuous Delivery Book DE Powered by Amazon Lambda & Microservices EMail address logged for 14 days, wrong addressed emails handled manually Slides