Its all about the domain honey engl

WPS - Workplace Solutions GmbH //// Hans-Henny-Jahnn-Weg 29 //// 22085 HAMBURG
IT’S ALL ABOUT THE DOMAIN, HONEY -
10 years of domain driven design
Dr. Carola Lilienthal, cl@wps.de, @cairolali
www.wps.de

19.01.2018 //// Seite 2WPS - Workplace Solutions GmbH
Dr. Carola Lilienthal
Geschäftsführerin
cl@wps.de
www.wps.de
+49 40 229 499-0
+49 40 229 499-299
+49 170 184 77 11
Diplom-Informatikerin
@cairolali
a @cairolali
cl@wps.de
www.llsa.de

Software
Architecture
Requirement
Engineering
Workplace
of the Future
Software
Development
Enjoyable business
software!
WPS – Workplace Solutions GmbH

Training Domain-Driven Design
Advanced Level Module – german or english
wps.de/ddd

WE ARE PROGRAMMER …

... AND WE LOVE TECHNOLOGY

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

SOFTWARE AS A REFLECTION OF THE DOMAIN

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

DOMAIN SPEAK – EXAMPLE PORT
Container
Container number
4300
Crane
Twistlock
Bill of lading

Domain
Lingo
Techno
Babble
?
MOTIVATION UBIQUITOUS LANGUAGE

Techno
Babble
Domain
Lingo

Fach-
sprache
Techno
Babble
Domain
Lingo

Domain
Lingo
Techno
Babble

Domain
Lingo
{
Techno
Babble
}
?

Domain
Lingo
{
Domain
Lingo
}

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

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…

DOMAIN SPEAK – EXAMPLE CHESS
Board
King
Pieces
Player
Chess clock

UBIQUTIOUS LANGUAGE – EXAMPLE CHESS
Board
Pieces
Player
Non-Human Player

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

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

LARGE PROJECTS
Require multiple teams
Development is done parallel
Each team is assigned to a specific part of the model
One big model?

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

ONE SHARED MODEL
Separate Use Cases

ONE SHARED MODEL
Separate Use Cases The model dispersed among use cases

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

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

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

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“

BUILDING BLOCKS
Wurzel-Entity
Entity
Entity
Entity
Entity
VO
VO VO
VO
VO VO VO VO
VO
VO
VO
VO
Aggregate
Service

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

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

GROSSE ZYKLEN VERSCHMUTZEN DAS SYSTEM
119 classes from 4 „bounded contexts“
+ 28 other classes in cylces
CYCLES

327 classe from 8 „bounded contexts“
need each other

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

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)

MEETUPS
@DDDger

CONFERENCES
Germanys first DDD conference

Dr. Carola Lilienthal
Geschäftsführerin
cl@wps.de
www.wps.de
+49 40 229 499-0
+49 40 229 499-299
+49 170 184 77 11
Diplom-Informatikerin
@cairolali
a @cairolali
cl@wps.de
www.llsa.de
Thanks for listening!

Its all about the domain honey engl

Recommended

Recommended

More Related Content

Similar to Its all about the domain honey engl

Similar to Its all about the domain honey engl (20)

More from Carola Lilienthal

More from Carola Lilienthal (12)

Recently uploaded

Recently uploaded (20)

Its all about the domain honey engl