Since Microservices have appeared as an architectural style to solve organizational problems and improve scalability the ideas of Domain-Driven Design have experienced a strong revival. On the one hand the guidelines of strategic design (DDD in the large) help us to cut the domain into domain-related bounded contexts. These bounded contexts than correspond with microservices. Within the bounded contexts tactical design (DDD in the small) with the ubiquitous language and the building blocks entity, value object, aggregate, service etc. give us guidance how to implement and structure our design. In this workshop we will show you the essentials of DDD and report on our ten yours experience with DDD. Short lectures, discussions and exercises will alternate with one another.
8. 19.01.2018 //// Seite 8WPS - Workplace Solutions GmbH
WHAT IS DDD ABOUT?
An approach to software development,
whose central feature is the implementation of a domain model
It simplifies
design and
development practice Software
Domäne
9. 19.01.2018 //// Seite 9WPS - Workplace Solutions GmbH
SOFTWARE AS A REFLECTION OF THE DOMAIN
10. 19.01.2018 //// Seite 10WPS - Workplace Solutions GmbH
STARTING DOMAIN DRIVEN DESIGN
At the beginning of a software project :
Focus on the domain in which the software is used
How do you create software that matches a domain?
Understanding software as a
reflection of the domain
Integrate core concepts and
domain elements into the
software
Depict their interrelationships
Create a domain model
11. 19.01.2018 //// Seite 11WPS - Workplace Solutions GmbH
DOMAIN SPEAK – EXAMPLE PORT
Container
Container number
4300
Crane
Twistlock
Bill of lading
12. 19.01.2018 //// Seite 12WPS - Workplace Solutions GmbH
Domain
Lingo
Techno
Babble
?
MOTIVATION UBIQUITOUS LANGUAGE
13. 19.01.2018 //// Seite 13WPS - Workplace Solutions GmbH
Techno
Babble
Domain
Lingo
MOTIVATION UBIQUITOUS LANGUAGE
14. 19.01.2018 //// Seite 14WPS - Workplace Solutions GmbH
Fach-
sprache
Techno
Babble
Domain
Lingo
MOTIVATION UBIQUITOUS LANGUAGE
15. 19.01.2018 //// Seite 15WPS - Workplace Solutions GmbH
Domain
Lingo
Techno
Babble
MOTIVATION UBIQUITOUS LANGUAGE
16. 19.01.2018 //// Seite 16WPS - Workplace Solutions GmbH
Domain
Lingo
{
Techno
Babble
}
?
MOTIVATION UBIQUITOUS LANGUAGE
17. 19.01.2018 //// Seite 17WPS - Workplace Solutions GmbH
Domain
Lingo
{
Domain
Lingo
}
MOTIVATION UBIQUITOUS LANGUAGE
18. 19.01.2018 //// Seite 18WPS - Workplace Solutions GmbH
UBIQUITOUS LANGUAGE
Use the common language in
All communications
Speech
Writing
Diagrams
In the code
Basically everywhere that is why it is called a ubiquitous language
19. 19.01.2018 //// Seite 19WPS - Workplace Solutions GmbH
LANGUAGE DOES NOT APPEAR OVERNIGHT
Weeks and months
Of hard work
A lot of focus
Find the key concepts
The first words in the ubiquitous language come usually
directly from the domain
Later own words are defined…
21. 19.01.2018 //// Seite 21WPS - Workplace Solutions GmbH
DOMAIN SPEAK – EXAMPLE CHESS
Board
King
Pieces
Player
Chess clock
22. 19.01.2018 //// Seite 22WPS - Workplace Solutions GmbH
UBIQUTIOUS LANGUAGE – EXAMPLE CHESS
Board
Pieces
Player
Non-Human Player
23. 19.01.2018 //// Seite 23WPS - Workplace Solutions GmbH
LANGUAGE IS A LIVING THING
Experiment with alternative expressions
The model and the language evolve
Then refactor the code
Rename classes, methods, modules
Conform to the new model
A Language has to be spoken:
Resolve confusion in conversation
25. 19.01.2018 //// Seite 25WPS - Workplace Solutions GmbH
TACTICAL AND STRATEGIC DESIGN
DDD gives modelling advice both at large and small scale
Strategic design
Divide your Domain into separated Bounded Contexts
Each Bounded Context has its own Domain Model and Ubiquitous Language
Context Mapping helps understanding the relations between Bounded
Contexts
Tactical Design
Inside a Bounded Context
Building Blocks: Entity, Value Object,
Aggregate, Service, Repository, Factory
26. 19.01.2018 //// Seite 26WPS - Workplace Solutions GmbH
LARGE PROJECTS
Require multiple teams
Development is done parallel
Each team is assigned to a specific part of the model
One big model?
27. 19.01.2018 //// Seite 27WPS - Workplace Solutions GmbH
THE OVERALL CONSISTENT MODEL
In the 1990th fruitless tried on data models
The idea was to create one model for an entire enterprise or even an entire
domain
High degree of coordination between teams
Often ends up in a big ball of mud
28. 19.01.2018 //// Seite 28WPS - Workplace Solutions GmbH
ONE SHARED MODEL
Separate Use Cases
29. 19.01.2018 //// Seite 29WPS - Workplace Solutions GmbH
ONE SHARED MODEL
Separate Use Cases The model dispersed among use cases
30. 19.01.2018 //// Seite 30WPS - Workplace Solutions GmbH
HOW TO FIND SUBDOMAINS?
Boarders within the business processes of the domain
Existing team and department boundaries(domain sections)
Exclusive domain experts
Contextual language
Data uniqueness
31. 19.01.2018 //// Seite 32WPS - Workplace Solutions GmbH
LIVING IN A BOX
Set explicit limits...
One team per bounded context
Maintain consistency within limits
No distraction from external affairs
A separate code base and database schema
Free design of a partial model by a team
Know the restrictions
Stay within the model boundaries
Work fast within your limits
32. 19.01.2018 //// Seite 33WPS - Workplace Solutions GmbH
TYPES OF DOMAINS WITH STRATEGIC DESIGN FRO DDD
Types of subdomains
Core domain
Supporting domain
Generic domain
Context Mapping
Shared Kernel
Customer/Supplier
Open-Host-Service
Published Language
Separate Ways
Anticorruption Layer
33. 19.01.2018 //// Seite 34WPS - Workplace Solutions GmbH
BUILDING BLOCKS = DESIGN PATTERNS
Services
Value Objects
Entities/
Aggregate
stateless
Domain concept are changeable
by the user and ensure their
consistency themself.
Unchangeable domain value with a
value range and validation
"Mikrolayering“
34. 19.01.2018 //// Seite 35WPS - Workplace Solutions GmbH
BUILDING BLOCKS
Wurzel-Entity
Entity
Entity
Entity
Entity
VO
VO VO
VO
VO VO VO VO
VO
VO
VO
VO
Aggregate
Service
35. 19.01.2018 //// Seite 36WPS - Workplace Solutions GmbH
WHAT WE SHOULD NOT BUILD
✘
ANEMIC DOMAIN MODEL
„anemic“ domain objects
Interfaces that have no meaning
Just get and set methods
A lot of String parameter
The domain functionality is not in
entities or value objects but in services
and UI
A lot of util, Helper and Manager classes
36. 19.01.2018 //// Seite 37WPS - Workplace Solutions GmbH
ANEMIC ROBUSTNESS IS MISSING
Design depth
Design is unclear and hard to
comprehend
Domain functionality is spread
throughout the whole system
Copy & Paste - Programming
Expensive maintenance
Duplicated code
Many Refactorings
Hard to test
37. 19.01.2018 //// Seite 38WPS - Workplace Solutions GmbH
GROSSE ZYKLEN VERSCHMUTZEN DAS SYSTEM
119 classes from 4 „bounded contexts“
+ 28 other classes in cylces
WHAT WE SHOULD NOT BUILD
CYCLES
38. 19.01.2018 //// Seite 39WPS - Workplace Solutions GmbH
WHAT WE SHOULD NOT BUILD
327 classe from 8 „bounded contexts“
need each other
40. 19.01.2018 //// Seite 41WPS - Workplace Solutions GmbH
BROWNFIELD STRATEGIC DESIGN
a tangled monolith with several domain models mixed with one another
Untangling:
1. Identify the different subdomains
in the monolith
2. Define the ubiquitous language
for each identified subdomain
3. Examine entities whether
decomposition or refactoring is
possible. Test coverage!
4. If necessary, duplication of the
entities and gradual expansion of the functionality that is not required.
5. Distribute the source code into bounded contexts
6. Start to separate the data of the bounded contexts in the database
7. Separate functional from technical code
41. 19.01.2018 //// Seite 42WPS - Workplace Solutions GmbH
DDD SEPARATES DOMAIN AND TECHNICAL CODE
Domain
Application
Port & Adapter
Gateway
Transformation
P & A
G/T
Web-Client
Rich Client
Web-Client
Rich Client
RDBMS
NoSQL
RDBMS
NoSQL
Everybody is telling us the same!
• Domain-Driven Design
(Evans 2004)
• Hexagonal Architecture
(Cockburn 1990/2005)
• Onion/Clean Architecture
(Jeffrey Palermo 2008 /
Robert C. Martin 2012)
• QUASAR = Quality Software
Architecture (SD&M 2004)
• T&M = Tools & Material Approach
(Züllighoven 1990)