Upgrade to Pro — share decks privately, control downloads, hide ads and more …

DDD Basics: Bounded Contexts, Modelling - Kortrijk Edition

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

Mathias Verraes

June 10, 2014

More Decks by Mathias Verraes

Other Decks in Technology


  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

  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