5 minute ignite about domain driven design: Tackling Complexity in the Heart of Software. Or how to provide a structure of practices and terminology for making design decisions that focus and accelerate software projects dealing with complicated domains.

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