Two of the six modules of the @DDDBE meetup on Strategic Domain-Driven Design on June 10, 2014 at Stack & Heap 1. Bounded Contexts 2. Modelling More at http://verraes.net/ or http://twitter.com/mathiasverraes

1. DDD Basics - Kortrijk Edition
June 10, 2014 - Belgium
@DDDBE — http://domaindriven.be

2. Kindly hosted by

3. We’ve got some great
(international) speakers,
but we need locations!
ping
@DDDBE
http://domaindriven.be

4. Aspects of
Domain-Driven Design

5. Tactical DDD
!
design patterns

6. Collaborative DDD
!
model storming

7. Strategic DDD
!
complexity, scale

8. Defining DDD (Yves)
Ubiquitous Language (Jef)
Bounded Contexts (Mathias)
Context Mapping (Stijn)
Modelling (Mathias)
Starting/Selling DDD (Tom)
Q&A / Lean Coffee

9. Bounded Contexts

10. “When something
is wrong,
something is
too big.”
— Leopold Kohr

11. Large complex systems:
harder to reason about

12. Large complex systems:
your mental model
!=
my mental model

13. Large complex systems:
subtle nuances
in meaning

14. Avoid a big unified
centralised model.

15. Classic example:
What is a product?

16. Split into
Bounded Contexts

17. Make Bounded Context
explicit
pure
independent
consistent within its
boundary

18. Benefits:
clarity
model integrity
freedom to
evolve separately

19. Drawbacks:
short term convenience
choosing the boundaries
how big is the problem?

20. Tricks

21. Inspired by
departments
teams
life cycles
business processes

22. What if this was an
off-the-shelf solution?

23. How much
communication goes on
between Bounded
Contexts?

24. Visualize!
!
Context Mapping
Model Storming

25. Modelling

26. Structural modelling
describes state

27. Structural modelling
inspired by
persistence concerns

28. Relational
Normalised
CRUD
Anaemic

29. “CRUD is our
industry’s
grand failure.”
— Greg Young

30. Ask your Domain Expert
about
State Changes!

31. Why does it change?
When does it change?
How often?
Who causes it?
By which rules?
What consequences?

32. !
!
The moving parts are
more interesting than the
stable parts

33. !
!
A Domain Model
is about:

34. state + structure
behaviour + change
temporal
roles + actors
business rules + invariants
causality + correlation
interaction
processes
workflows + transitions
intention + consequence
failure …

35. Modelling:
Make the implicit explicit

36. example
!
Intentions:
Command Objects
Consequences:
Domain Events

37. Intention
ProtectionInterpretation
Automation
user sends Commands
manage processes
domain model
sends Events,
guards consistency
create read models
from Events
DTO
Commands
Events

38. @mathiasverraes
http://verraes.net