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
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
Event Storming: Alternatives
•Domain Story Telling: Process-oriented
•Context Mapping: List contexts
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 23
Slide 23 text
Bounded Context
Bounds
Model i.e.
Code
Ubiquitous
Language
Slide 24
Slide 24 text
Ubiquituous Language
Database
Code Software Engineers
Domain Experts
Slide 25
Slide 25 text
Invoicing
Process
Bounded Context Example
Customer who pays the bill
Delivery
Customer who the products
are sent to
Slide 26
Slide 26 text
Parcel left
warehouse
Identify Candidates for Bounded Contexts
•Areas between swim lanes and pivotal events are
good candidates for Bounded Contexts
Swimlane
Delivery
Order accepted Swimlane
Invoicing
Slide 27
Slide 27 text
Identify Candidates for Bounded Contexts
•Areas between swim lanes and pivotal events are
good candidates for Bounded Contexts
Invoicing
Delivery Process
Order Processing
Slide 28
Slide 28 text
Identify Candidates for Bounded Contexts
•Only Candidates: Still design needed!
•Reimbursements handled by invoicing?
•Return handled by delivery process?
Invoicing
Delivery Process
Order Processing
Slide 29
Slide 29 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 30
Slide 30 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 31
Slide 31 text
Bounded Context: Results
•Bounded Context = model for business functionality
•Small, loosely coupled models / modules
•Changes probably contained to one bounded context
Core Domain
•Core domain = motivation for the project
•Reduce the complexity of the model
•Focus on maintainability of this part of the system
Slide 36
Slide 36 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 37
Slide 37 text
Core Domain: Result
•Clear focus
•Better understanding of the domain
Slide 38
Slide 38 text
Strategic Design
Slide 39
Slide 39 text
Why Strategic Design?
•Somehow teams need to collaborate
•Core Domain should be supported by other domains.
•No way to ensure the success of the Core Domains
just with architecture.
•So: need to prioritize core domain on the
organizational level.
Slide 40
Slide 40 text
What Is Strategic Design?
•Patterns that deal with collaboration
•Customer / supplier:
Supplier team supports customer team
•Conformist:
Conformist teams follows the other teams.
•Customer / supplier and conformist are opposites.
Slide 41
Slide 41 text
Challenge
•My experience: Hard to adapt
•Too complicated
•Not intuitive?
•Only covers teams that work on Bounded Contexts
Slide 42
Slide 42 text
Not Strategic Design but
Team Topologies
Slide 43
Slide 43 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 44
Slide 44 text
Team Topologies
Stream-aligned team
Platform team
Enabling team
Complicated
Subsystem
team
XaaS
Collaboration
Facilitating
XaaS
Slide 45
Slide 45 text
Team Topologies
Order Processing
Kubernetes / CI Team
Delivery
Optimization
Invoicing
Delivery
XaaS
Architecture
Collaboration
Facilitating
XaaS
Slide 46
Slide 46 text
Team Topologies: Result
•Team setup defined
•Collaborations defined
Example
Platform Team(s)
Stream-aligned Team
Stream-aligned Team
Stream-aligned Team
Slide 52
Slide 52 text
Example
•Shall we introduce platform team(s)?
•Some common functionalities
•Might make sense
Slide 53
Slide 53 text
Example
•Toxic environment
•Problems are not communicated.
•Punishment if problems are communicated
•Mistrust
Slide 54
Slide 54 text
Example
•Can’t trust the platform team
•Platform team won’t make problems transparent
•So: Stream-aligned team might not reach goals
•But stream-aligned team will be blamed
•So: Rather build platform yourself
Slide 55
Slide 55 text
The Problem with Org Charts
•Humans don’t necessarily work according to org chart
•I.e. you need to solve people problems.
Slide 56
Slide 56 text
Tactical Design
Slide 57
Slide 57 text
Why Tactical Design?
•Object-oriented concepts
•Make a lot of sense to build good object-oriented
systems!
Slide 58
Slide 58 text
Tactical Design
Entity
Value
Object
Domain
Event
Identity:
a person
Value:
2€, 2m
Something
has
happened.
Matters to
domain
experts
Slide 59
Slide 59 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 60
Slide 60 text
Tactical Design
Entity
Value
Object
Aggregate Factory
Repository
Service
Domain
Event
Logic doesn‘t fit in
Entities /
Aggregates
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.
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
Framework?
•Tactical patterns define dependencies
•E.g. Services might use Aggregates
•Might use architecture management tools to enforce
dependencies
•https://software-architektur.tv/
tags.html#Architecture%20Management
Slide 69
Slide 69 text
Design Level Event
Storming
Slide 70
Slide 70 text
Design-Level Event Storming
Actor
Command
System
Domain
Event
External
System
Policy
Command
Read
Model
UI
Slide 71
Slide 71 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 72
Slide 72 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 73
Slide 73 text
Event Sourcing
Slide 74
Slide 74 text
Event Sourcing
•Store events that lead to a specific state
•Might also store state (optional)
•System of record: State or events
Slide 75
Slide 75 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 76
Slide 76 text
State
Events
Calculate
State on Demand
State+
Events
Event
Sourcing
Slide 77
Slide 77 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 78
Slide 78 text
CQRS
Slide 79
Slide 79 text
CQRS
•Command Query Responsibility Separation
•E.g. separate read and write
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 82
Slide 82 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?
Layers
•Actual pattern in the original DDD book.
•Separate logic
•To isolate logic in one place
•To make the system easier to understand
•DDD does not cover patterns for e.g. UI
Persistence
Logic
UI
Slide 86
Slide 86 text
Hexagonal
•Business logic exports
ports (interfaces)
•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 87
Slide 87 text
https://software-architektur.tv/2024/05/29/episode218.html
Ports and Adapters
Slide 88
Slide 88 text
Conclusion
Slide 89
Slide 89 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