Domain Driven Design The Basics
summary
Domain-Driven Design is presented as a way to stop building the wrong thing by defining a shared ubiquitous language, mapping bounded contexts with a context map, and modelling flows with event storming. Basics covered: domain events, commands, aggregates, value objects, repositories per aggregate, and translating between domain and persistence. Advice: apply DDD only for complex domains, start simple, evolve boundaries, and be cautious adopting CQRS or event sourcing — use them selectively rather than across the whole system.
AI-written summary · about
chapters (17)
- 0:00Introduction and speaker intro
- 3:35What is Domain Driven Design
- 7:52Why communication matters
- 10:22Ubiquitous language explained
- 13:55Domains and subdomains
- 16:07Bounded contexts
- 17:53Modeling out loud
- 20:04Event storming basics
- 21:11Context maps
- 24:42Domain events and aggregates
- 28:17Implementation basics
- 31:53Entities and value objects
- 33:45Services and clarity
- 36:45Domain events in code
- 38:10Repositories in DDD
- 39:34Next steps and resources
- 42:44Q&A: Deciding DDD scope
related talks
38mWhat I talk about when I talk about Domain Driven design
42mDomain Driven Design - So Your Code Speaks Plain Language
55mDomain-Driven Design: back to the roots
50mGetting Started with Domain-Driven Design without Fighting the Wrong Battles
48mDomain-Driven Design tactically and practically
59mDomain-Driven Design - Where Rubber Meets the Road
49mHow to cook Domain Driven Design
47mDomain-Driven Design: A Complete Example