Preventing Emu Wars with Domain-Driven Design
summary
Compares a failing “update order” API to the Emu War, shows a real e‑commerce bug chain (race conditions, empty shipments) caused by a vague order updated event, and uses 5 Whys, Event Storming and Ubiquitous Language to reframe requirements. Replaces the monolithic endpoint with place supplementary order, a split order received/order submitted flow, a cancel endpoint and a backout timer; result is far fewer cross‑service interactions, smaller PRs (avoids 2,000‑line reviews), easier tests and far less accidental complexity.
AI-written summary · about
chapters (7)
- 0:00Introduction
- 1:27Emu Wars and DDD
- 13:28E-commerce order updates
- 26:34Event storming and DDD smells
- 33:04Reframing problem statements
- 41:28Simplifying solutions with domain-driven design
- 46:29Summary
related talks
45mLearning to Love DDD - a Tale of Two Products
37mBuilt to last: A domain-driven approach to beautiful systems
58mModernizing an existing system to take a more domain-driven approach
58mFinding your service boundaries - a practical guide
54mThinking in Events
40mController Control: Designing Domains for Web Applications
52mNavigating complexity in event-driven architectures: A domain-driven approach
47mGetting modules right with Domain-driven Design