What I talk about when I talk about Domain Driven design
summary
Domain‑driven design is an iterative, evolutionary way to put the business model into code, anchored on two pillars: ubiquitous language and model-driven design. Concrete practices that appear and work in the field include event storming workshops, CQRS and event sourcing for hard problems, and ports‑and‑adapters for implementation. The common failure is not technical but social: the domain language never reaches the codebase, so models drift. Practical path: start with tactical DDD in code, ship, gather feedback, then evolve into strategic splits (bounded contexts/aggregates) only when the model proves it needs them.
AI-written summary · about
chapters (15)
- 0:00Introduction to DDD
- 2:51Bauhaus and DDD origins
- 7:07Eric Evans and DDD principles
- 10:40Ubiquitous language and model design
- 12:45Aggregates and bounded contexts
- 16:13Bauhaus chaos and evolution
- 19:21DDD popularity and Vaughn Vernon
- 21:05Strategic vs tactical DDD
- 23:10DDD patterns and practices
- 27:43DDD influences and derivatives
- 28:04CQRS and microservices
- 30:29Event storming and team topologies
- 33:17Data mesh and DDD
- 35:44Core principles of DDD
- 37:50Q&A
related talks
46mDomain Driven Design The Basics
48mDomain-Driven Design tactically and practically
55mDomain-Driven Design: back to the roots
59mDomain-Driven Design - Where Rubber Meets the Road
45mDon't Overdose on Domain-Driven Design
42mDomain Driven Design - So Your Code Speaks Plain Language
49mHow to cook Domain Driven Design
38mModel-Driven Design