1. How does
Domain-Driven
Design work?
Tomaš Maconko
tomasmaconko@gmail.com

2. What is it?
“That’s just a rubbish theory!”
“Its just another way to structure your code!”
“Its hard to understand!”
“It requires lots of useless coding!”
“Nobody wants to use it!”

4. What is it?
“Domain-driven design (DDD)
is an approach to software
development for complex
needs by connecting
the implementation to an
evolving model.”

5. What is complexity?
•Business is the domain
•Complexity is the domain (problem) itself
•Domain consists of complex processes,
workflows, rules etc.
•Different specialists collaborate together to
make business value

7. Domain areas
Core subdomain
Supporting subdomains

8. Core subdomain and supporting subdomains
• DDD requires you to examine the business deeply
• It enables you to split up the problem into smaller
pieces (subdomains) to outline the core piece (core
subdomain)
• Allows you to pay attention to each piece separately
(even to work in different teams) and concentrate
mostly on the core

9. Core subdomain

10. Lets look inside
• Marketing
• Sales
• Billing
• Production
• Logistics
• Operations
• …

12. Bounded context
•A pattern in Domain-
Driven Design
•A chunk of solution
space
•Helps dealing with
large models
•Ubiquitous language

13. Ubiquitous language

14. Ubiquitous language
•Requires people in same bounded context using
same terms (dictionary)
•Same term is unambiguous for all team
members (domain experts, developers, QA,
etc.)
•Defined and maintainable by whole team

15. Car (production): engine,
wheels, body, …
Car (billing): car parts
expenses, salaries
Car (marketing): photo, video, description, …

17. Value object
•Does not have
identity
•Comparable by all its
attributes
•IMMUTABLE!
•Allows to encapsulate
business rules

18. Value
object

19. Entity
•A set of attributes and
verbs
•Has identity (engine ID
number)
•Cannot (logically) work
without aggregate
•Mutable

20. Entity

21. Aggregate and aggregate root
•Entity
•Joins related entities and value objects
•Encapsulates complex and state-dependent
requirements in domain classes
•It is highly recommended (required) to have
single aggregate per transaction

22. Aggregate

23. Aggregate root

24. Respository
• Encapsulates aggregates persistence and retrieval
• Persistence ignorance
• Can be used as abstraction for different underlying technologies
(SQL, NoSQL, web-services, caching, etc.)
• One repository per aggregate

25. Repository

27. How to combine stuff together?
2. Stop
pedal
pressed!
1. I listen for
stop pedal
pressed
1. I listen for
stop pedal
pressed
3. I handle it
3. I handle it
4. Started
stopping
4. Stop
lights
turned on
1. I listen for
acceleration
pedal pressed

28. Domain event
•Messages in past tense
•Result of completed command
•Integrates aggregates or bounded contexts with
minimal coupling and dependencies
•Reduces the number of changes in existing code
•Improves responsiveness (asynchronous
processing)

30. Pros
• Involves team into domain analysis
• Helps splitting and understanding
the domain
• Unambiguous terms
• Changes the way developers think
about solution
• Strong domain model
• Clean and maintainable code
DDD
Domain

31. Cons
•Requires team time and effort for analysis
•Requires stronger skills on modeler side and
OOP
•Complicates small systems
•Requires time to define UL
DDD

32. So, what next?
• CQRS
• Event sourcing
• Microservices