Domain-Driven Design: Hidden Lessons from the Big Blue Book
summary
Argues that concrete techniques beat vague principles: use event storming to map entire business processes on a wall so developers and experts share a single model; treat bounded contexts as socio‑technical boundaries that match teams to reduce cross‑team work; apply core domain distillation (example: 95% revenue from one product) to choose architecture. Cites thousands of deployed devices (New York, smart boats), a government case where a textbox change required five teams, and studies showing multi‑team work takes an order of magnitude longer.
AI-written summary · about
chapters (12)
- 0:00Becoming an expert beginner
- 1:24Discovering domain knowledge
- 4:03Current technology trends
- 6:57Importance of exploration
- 10:25Introduction to event storming
- 13:35Expanding on domain techniques
- 15:27Using design heuristics
- 21:15Contextualizing design decisions
- 25:59Aligning design with business
- 29:00Organizational challenges
- 32:21Socio-technical architecture
- 35:23Summary and future outlook
related talks
39mDomain-Driven Design: Hidden Lessons from the Big Blue Book
57mDomain-Driven Design in Productland
58mDDD really matters!
50mIt's All About the Domain, Honey - Domain-Focused Architecture with DDD
01h 11mAn introduction to DDD
54mDomain-Driven Design and Team Topologies for Product-led Organizations
55mDomain Driven Design in practice - how to draw your domain boundaries IRL
38mDomain-Driven Design & Team Topologies Hands-on