Strategic Domain-Driven Design for dummies
summary
Shows how strategic DDD turns a tangled monolith into separable modules by mapping business subdomains (shop example: user/employee accounts, storage, shelf, cart, payments) into bounded context code areas, using heuristics to find them: name gaps, same word different meaning, same data different world, and process role changes. Uses pragmatic tactics — copy‑paste to seed contexts, then refactor, apply ubiquitous language and selectively choose architectures (e.g. hexagonal architecture where needed). Outcome: more classes but clearer ownership, easier extraction to services, shorter lead times and fewer risky guesses.
AI-written summary · about
chapters (6)
- 0:00Strategic DDD intro
- 7:58Problem vs solution space
- 15:30Monoliths become unmaintainable
- 26:17Bounded contexts & language
- 33:24Identifying bounded contexts
- 39:50Q&A
related talks
44mStrategic Domain-Driven Design for dummies
38mWhat I talk about when I talk about Domain Driven design
47mDomain-Driven Design: A Complete Example
48mDomain-Driven Design tactically and practically
01h 00mFrom Domain Driven Design DDD to Delivery
56mMicroservices and Domain-Driven Design — The Strategic Parts
50mGetting Started with Domain-Driven Design without Fighting the Wrong Battles
45mDon't Overdose on Domain-Driven Design