Learning to Love DDD - a Tale of Two Products
summary
Compares two real products: a 2008 school lunch/merch platform that used one overly generic data model (orders, items, min/max) and accumulated crippling technical debt, versus a 2015 healthcare payments platform that adopts Domain-Driven Design, uses event storming and an event-driven architecture, co-creates a bounded context and ubiquitous language, then refactors into a V2 that delegates decision engines to programs. Shows concrete wins: simpler routing adapters, faster rollout to many schemes, ability to retire V1, and tooling (ContextDiff) to keep code-language aligned.
AI-written summary · about
chapters (13)
- 0:00Welcome
- 3:35DDD language and models
- 6:47Flexi Schools and Lantern Pay
- 9:15Explicit better than implicit
- 16:57Bounded contexts clarity
- 19:02Co-creating ubiquitous language
- 27:03Event storming terminology
- 30:09Continuous integration for conversations
- 32:56Embrace continuous change
- 39:19Conway’s law flexibility
- 40:42Case for refactoring
- 43:07Recap key lessons
- 43:28Open source tool alignment
related talks
38mIntroDDDuction
57mDomain-Driven Design in Productland
01h 11mAn introduction to DDD
01h 05mGetting to DDD: Pragmatic or Principled?
39mDomain-Driven Design: Hidden Lessons from the Big Blue Book
01h 04mDomain Driven Design: The Good Parts
50mIt's All About the Domain, Honey - Domain-Focused Architecture with DDD
59mDomain Driven Design: The Good Parts