Don't Overdose on Domain-Driven Design
summary
Argues that DDD succeeds only when the domain—not architecture or frameworks—drives decisions, and gives concrete practices: start with domain prototyping (monolith or client-side JS, add DB/server only when required), identify a small core domain and treat invoicing/shipping/order as candidate subdomains based on business strategy, split by bounded contexts defined by functionality, apply tactical patterns (entities, aggregates, repositories) but don’t mistake them for DDD, and use collaborative modeling like event storming to get domain experts and teams aligned.
AI-written summary · about
chapters (10)
- 0:00Introduction and welcome
- 2:30Domain-Driven Design basics
- 6:24Core domain and subdomains
- 11:44Business strategy importance
- 16:16Bounded contexts explained
- 24:32Tactical design patterns
- 27:44Strategic design and team dependencies
- 36:03Social-technical systems
- 39:19Collaborative modeling techniques
- 42:58Conclusion and key takeaways
related talks
31mIs Domain-Driven Design Overrated?
38mWhat I talk about when I talk about Domain Driven design
59mDomain-Driven Design - Where Rubber Meets the Road
55mDomain-Driven Design: back to the roots
47mDomain-Driven Design: A Complete Example
44mStrategic Domain-Driven Design for dummies
35mTrivialization of DDD or Not?
29m20 Years of Domain-Driven Design: What I’ve Learned About DDD