How EventStorming Transformed Our Domain Modeling Process
summary
EventStorming turns a vague spec into a working domain model in hours not weeks by running a physical workshop with lots of orange sticky notes, a facilitator, and timeboxed phases: 10–15 minutes chaotic exploration, ordering via pivotal events and swimlanes, then commands→APIs, read models for UI and policies that become domain logic. It exposes integrations, hotspots and service boundaries so teams map bounded contexts and aggregates (used at a large pharmacy chain) — not a perfect fix but a cheap, fast way to design code.
AI-written summary · about
chapters (14)
- 0:00Introduction to EventStorming
- 2:21Problems with current modeling
- 7:20What EventStorming solves
- 10:35EventStorming explained
- 12:23Preparing the workshop
- 16:16Chaotic exploration phase
- 18:04Enforcing timeline
- 20:15Actors and hotspots
- 22:23Process modeling
- 24:33Finding bounded contexts
- 26:21Discovering aggregates
- 27:45Limitations and tips
- 29:09Facilitator’s role
- 30:58Summary and closing
related talks
50mHow EventStorming Transformed Our Domain Modeling Process
49mFrom Days to Hours: How EventStorming Transformed Our Domain Modeling Process
01h 02mEvent Storming for domain-driven design
47mESSENTIALS - Event Storming for fun and profit
14mSession 1: Event Storming
40mEventStorming Lessons Learned - tens of thousands of post-its later
48mA universe full of events - EventStorming
55mEvent Storming - how to shorten the distance between IT and Business