Strategic Domain-Driven Design for dummies
summary
Argues that using ubiquitous language and bounded contexts closes the gap between customer intent and delivered software, illustrated with a concrete shop domain where "product" becomes three different models for storage, shelf and online basket and "user" splits into employee, customer, payer and receiver. Gives four practical signals to find boundaries — unique meaning, same data used differently, various names in one process, and no interaction — and recommends mapping each context to its own model, architecture and team.
AI-written summary · about
chapters (8)
- 0:00Introduction and motivation
- 1:40What is Domain-Driven Design
- 7:04Ubiquitous language explained
- 14:53Bounded context fundamentals
- 23:27Problems with simplification
- 31:20Finding context boundaries
- 39:33Benefits of bounded contexts
- 42:39Next steps and resources
related talks
44mStrategic Domain-Driven Design for dummies
01h 02mDomain-Driven Design in ProductLand
41mDomain-Driven Design: Hidden Lessons from the Big Blue Book
38mWhat I talk about when I talk about Domain Driven design
48mDomain-Driven Design tactically and practically
56mMicroservices and Domain-Driven Design — The Strategic Parts
47mDomain-Driven Design: A Complete Example
55mDomain-Driven Design: back to the roots