Getting modules right with Domain-driven Design
summary
Domain-driven Design is used to find vertical module boundaries by running event storming workshops, then mapping pivotal events (for example application submitted → pre‑scoring green/red) to boundary context candidates and checking coupling with main message flow modeling. Implementation guidance includes splitting rules into aggregates, deriving data only from behavior, keeping only the aggregate root public (no direct references between aggregates), and writing unit tests that mirror the ubiquitous language.
AI-written summary · about
chapters (14)
- 0:00Introduction to modularity
- 2:27Domain driven design basics
- 5:34Understanding domain experts
- 10:35Event storming for modeling
- 14:27Defining bounded contexts
- 16:44Purpose of bounded contexts
- 21:05Refining context boundaries
- 22:55Message flow modeling
- 27:11Bounded context design canvas
- 29:30Tactical DDD design patterns
- 34:33Identifying aggregates
- 37:15Domain modeling perspective
- 41:23Ubiquitous language in code
- 43:58DDD challenges and conclusion
related talks
56mMicroservices and Domain-Driven Design — The Strategic Parts
01h 00mFrom Domain Driven Design DDD to Delivery
47mDomain-Driven Design: A Complete Example
38mWhat I talk about when I talk about Domain Driven design
55mDomain-Driven Design: back to the roots
46mDomain Driven Design The Basics
45mDon't Overdose on Domain-Driven Design
59mDomain-Driven Design - Where Rubber Meets the Road