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.