DDD Basics: Bounded Contexts, Modelling - Kortrijk Edition

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

Transcript

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 Protection Interpretation 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