From Domain Driven Design DDD to Delivery
summary
Argument: Domain‑Driven Design maps business core/generic/supporting subdomains to technical boundaries so strategy yields deployable units; microservices are a deploy option not a necessity. Demonstrates a concrete toolchain: a context-mapper CML file that generates context maps, BDD/Gherkin glue for acceptance tests, and an order aggregate emits domain events pattern that records past‑tense events for downstream EDA. Shows integration choices — shared kernel vs anti-corruption layer — and recommends event storming to discover bounded contexts that teams can own and evolve independently.
AI-written summary · about
chapters (10)
- 0:00Introduction to DDD
- 3:58Identifying subdomains
- 13:31Domain experts and ubiquitous language
- 20:00Bounded context explained
- 28:53Physical and ownership boundaries
- 33:07Integrating bounded contexts
- 42:00Simple vs complex business logic
- 45:13Domain model pattern
- 55:14Event storming basics
- 58:28DDD and modern architectures
related talks
47mDomain-Driven Design: A Complete Example
56mMicroservices and Domain-Driven Design — The Strategic Parts
38mWhat I talk about when I talk about Domain Driven design
44mStrategic Domain-Driven Design for dummies
45mDon't Overdose on Domain-Driven Design
47mGetting modules right with Domain-driven Design
46mDomain Driven Design The Basics
59mDomain-Driven Design - Where Rubber Meets the Road