The document discusses domain-driven design (DDD) as a method to manage complexity in software development, emphasizing the importance of adaptability to change. It outlines key concepts such as bounded contexts, domain modeling, and various building blocks like entities, value objects, and domain events. The document also highlights advantages of DDD in complex and rapidly evolving business domains, while noting potential challenges such as integration complexity and the difficulty of domain modeling.

2. https://nl.linkedin.com/in/iefcuynen
@iefcuynen
Ief Cuynen
Domain Driven Design
Tackling Complexity in the Heart of Software
https://nl.linkedin.com/in/

3. It is not the strongest of the species
that survives, nor the most intelligent
that survives.
It is the one that is most adaptable to
change
- Charles Darwin

4. Big Ball Of Mud

5. Strategic modeling

6. Domain & subdomains
Yep, same picture

7. Bounded contexts
Still the same

8. Context Maps: high level integration overview
Types
• Partnership
• Shared Kernel
• Customer-Supplier
• Conformist
• Anticorruption Layer
• Published Language
• Separate Ways
• Big Ball Of Mud

9. Old school domain modeling
airCraft.setRoute(newRoute)
airCraft.go()
Technical methods
Separate Lingo
• Business
• Architecture
• Developer
• Code

10. Domain driven Modeling
Ubiquitous language
business = architecture = developer = code
Business methods
flightplan.assignFlightRoute(route)
flight.takeOff()

11. Domain model – building blocks
 Entities
 Have an unique identity
 Continuous change over time
 Built up from value objects
 E.g Customer
 Value objects
 Objects that matter only as the combinations of their attributes
 No identity
 Immutable
 E.g. money, address

12. Domain model – building blocks
 Domain Services
 Connects to another remote domain model for interaction
 E.g. FlighplanFinder
 Aggregates
 Cluster of domain objects that can be treated as a single unit.
 E.g. Invoice & invoice lines
 Domain Events
 Business events fired after change of aggregate

13. Hexagonal Architecture

14. CQRS Command Query Responsibility Segregation

15. Command and Query models
 Command
 Domain model
 Publishes busines events
 Query
 Built using domain events
 Best fit for each specific goal
 GUI
 Data mining
 Reporting
Command Model
X
Command Model
Y
Query Model A Query Model B

16. Event sourcing
 Store the domain events in an event store
 Perfect match with CQRS
 Events can be replayed to
 build new query models
 Rebuild existing query models

17. DDD excels in
 Complex business domains
 Fast changing busines domains
 Scalable applications
 Asynchronous communication
 Micro services (= bounded context)
 Push and pull
 Caching
 Failure proof applications

18. DDD caveats
 Domain modeling is hard
 Can be expensive
 Complex integration
 Eventual consistency