Key Principle
Event Storming (Alberto Brandolini) is a rapid, tactile, collaborative design technique that encodes a critical sequencing insight: Domain Events first (what happens), then Commands (what triggers it), then Aggregates (what handles it), then boundaries (what contains it). This forces business-process thinking before data-structure thinking — the opposite of how most technical teams naturally approach design.
Why This Matters
Without a structured discovery technique, teams default to database-first or API-first design, producing models disconnected from business reality. Event Storming's constraints — penny-cost mistakes (sticky notes, not code), everyone contributes equally (tactile and visual, no laptop hierarchy), and Domain Experts and developers forced into the same physical modeling activity — generate breakthroughs in understanding that meetings and documents cannot.
Good Examples
Practical format: Orange stickies (events, past tense) placed left-to-right on a wide wall. Light blue stickies (commands, imperative) placed left of their corresponding events. Pale yellow stickies (Aggregates) placed behind command/event pairs. Solid lines for Bounded Context boundaries, dashed lines for Subdomain boundaries. Sessions run 2-3 hours each over 3-4 days. (Chapter 7)
Direct output to tactical design: Event Storming produces the exact artifacts needed for implementation — Domain Events (Chapter 6), Commands (Chapter 6), and Aggregate boundaries (Chapter 5). It bridges strategic and tactical design in a single collaborative activity. (Chapter 7)
Modeling Spike: The initial Event Storming session at project inception serves as a knowledge investment. It surfaces the Ubiquitous Language, identifies Bounded Context boundaries, and reveals the primary Domain Events — all before any code is written. (Chapter 7)
Counterpoints
Modeling Debt: When timeboxing prevents completing a modeling task properly, the incomplete understanding becomes modeling debt. "The worst thing you could do now is to just forget everything that you learned from the modeling efforts that called out for a different, improved design." (Chapter 7). Unlike vague "technical debt," modeling debt can be made specific — the sticky notes are the artifact recording what was understood but not yet implemented.
Knowledge acquisition vs. delivery pressure: "Knowledge acquisition is both a Scrum tenet and a major goal of DDD but is largely ignored in exchange for relentless delivery with Scrum." (Chapter 7). The causal chain: sprint pressure → teams drop modeling → Ubiquitous Language degrades → developers build wrong abstractions → Big Ball of Mud. The fix: treat modeling as delivery, not overhead. (Chapter 7)
Key Quotes
"Knowledge acquisition is both a Scrum tenet and a major goal of DDD but is largely ignored in exchange for relentless delivery with Scrum." — Vaughn Vernon, Chapter 7
"The worst thing you could do now is to just forget everything that you learned from the modeling efforts that called out for a different, improved design." — Vaughn Vernon, Chapter 7
Rules of Thumb
- Sequence discovery as: Events → Commands → Aggregates → Boundaries
- Use physical sticky notes on a wide wall, not digital tools (at least initially)
- Include Domain Experts and developers as equal participants
- Timebox sessions (2-3 hours) but track modeling debt explicitly
- Treat modeling sessions as delivery work, not overhead
Related References
- Domain Events and Event Sourcing - The primary artifact Event Storming discovers
- Aggregate Design Rules - Aggregate boundaries emerge from Event Storming
- The Core Framework: Strategic Before Tactical - Event Storming operationalizes the knowledge acquisition principle