Domain-Driven Design in Productland
summary
Argues that applying Domain-Driven Design to product teams requires concrete practice: use event-driven models to get trustworthy experiment data instead of brittle BI on legacy databases (example: detecting transfers via cancellation+rebook scripts created accidental complexity); prefer pairing across disciplines and short deploy cycles (some teams deploy experiments in a day, others wait two weeks) to cut handoffs; keep separate surface and implementation languages; prioritize design integrity so models stay ready to evolve and experiments stay cheap and clear.
AI-written summary · about
chapters (12)
- 0:00Welcome and introduction
- 1:51DDD in product development
- 5:00Mindset and learning challenges
- 12:13Cross-discipline collaboration
- 20:41Product strategy vs DDD determinism
- 28:10Flow and experimentation friction
- 31:22Language differences in DDD
- 37:43User-facing vs implementation language
- 42:01Customer count and product space
- 46:00Design integrity over technical debt
- 51:20Predicting future needs
- 55:36Closing insights and Q&A
related talks
38mDomain-Driven Design: Hidden Lessons from the Big Blue Book
39mDomain-Driven Design: Hidden Lessons from the Big Blue Book
58mDDD really matters!
54mDomain-Driven Design and Team Topologies for Product-led Organizations
45mLearning to Love DDD - a Tale of Two Products
50mIt's All About the Domain, Honey - Domain-Focused Architecture with DDD
38mDomain-Driven Design & Team Topologies Hands-on
01h 11mAn introduction to DDD
