Domain Prototyping or Design Is How It Works
summary
Starts by arguing for building a tiny, working domain core first and iterating outward: event storming to choose a small bounded context, implement a one‑machine prototype in TypeScript, run user tests every 3–4 weeks with five real users, and do rapid rewrites—six full iterations in eight weeks—before adding databases or network topology. Team uses mob programming, later adds REST, microservices and Kubernetes. Result: earlier feedback, fewer wrong assumptions, and an estimated saved 120–150K by dropping an unnecessary bounded context.
AI-written summary · about
chapters (19)
- 0:00Intro
- 1:05Design Steve Jobs
- 8:12Best practices
- 9:01Patterns
- 9:37Planning fallacy
- 12:40OODA loop
- 15:50Dualtrack agile
- 18:00Four phases
- 26:28Framework
- 27:55Evolutionary Design
- 28:58How did it work
- 29:56The team
- 30:47Liftoff workshop
- 31:22Milestone 1 6 iterations
- 32:38Milestone 1 2 iterations
- 33:37Milestone 2 conception
- 36:45Challenges
- 39:50Questions
- 41:17Any Questions
related talks
51mUXDD: A New Pragmatic Methodology for Domain Modeling and User Experience.
38mDomain-Driven Design & Team Topologies Hands-on
57mDomain-Driven Design in Productland
54mDomain-Driven Design and Team Topologies for Product-led Organizations
37mBuilt to last: A domain-driven approach to beautiful systems
45mDomain-Driven Design in Micro Frontends
39mVague But Exciting
43mThe Prototype Mindset