Event Storming with AI: Facilitating Domain Discovery Sessions
Event storming surfaces the real business process before a line of code is written. How to use AI as a facilitation partner — generating domain events, spotting missing actors, and turning sticky notes into a bounded context map.
Event storming is a workshop technique for discovering a business domain by mapping out everything that happens as a sequence of domain events — "Order Placed," "Payment Captured," "Shipment Dispatched" — before any discussion of classes, tables, or APIs. The point is to surface the real process, including the parts nobody wrote down, before architecture decisions lock anything in.
The problem event storming solves
Teams that skip domain discovery and jump to schema design tend to model the system they assume exists, not the one that actually does — and the gaps surface as production bugs six months later ("wait, what happens when a payment is captured but the warehouse is out of stock?"). Event storming forces those edge cases into the open early, when they cost a sticky note instead of a migration.
Where AI fits in the workshop
AI doesn't replace the domain experts in the room — it can't know your specific business rules. What it's genuinely useful for is the structuring and gap-finding work around the session: generating a first-draft event timeline to react to (easier to correct than to generate from scratch), and afterward, systematically checking the captured events for missing actors, unhandled failure paths, and inconsistent naming.
| Workshop stage | Where AI helps | Where it doesn't |
|---|---|---|
| Priming / draft timeline | Generate a plausible first-draft event sequence from a process description, to react to and correct rather than start from a blank wall | Cannot know undocumented business rules — the draft is a starting point, not ground truth |
| Live session | Not really — this is a human facilitation exercise | AI in the room slows down the human discussion it's meant to accelerate |
| Post-session cleanup | Spot missing actors, inconsistent event naming, and unhandled failure branches in the captured events | Still needs a domain expert to confirm which gaps are real vs. genuinely out of scope |
| Bounded context mapping | Propose context boundaries from clusters of related events, as a starting hypothesis | Team ownership and organizational boundaries matter as much as event coupling — human judgment call |
Worked example: post-session gap analysis
Context: Here is the domain event timeline captured from our event storming session for an order fulfillment process:
[paste the ordered list of events, e.g. Order Placed → Payment Authorized → Inventory Reserved → Order Confirmed → Shipment Created → Order Delivered]
Task: Review this timeline and identify gaps.
For each gap, categorize it as one of:
- Missing failure path (what happens when a step fails — payment declined, inventory unavailable, etc.)
- Missing actor or system (a step implies an actor/system not represented anywhere in the timeline)
- Ambiguous event (the event name doesn't make clear what specifically triggered it or what state it represents)
- Ordering question (a plausible alternate ordering that changes the guarantees the system needs to provide)
Do not invent business rules — flag the gap and the question to ask the domain expert, don't guess the answer."Don't invent business rules" is doing the real work in that prompt. The value of this pass is a sharper list of questions for the domain expert, not AI-generated answers to questions only they can answer.
From events to bounded contexts
Once the event timeline is solid, clusters of tightly related events (all the events one team owns and reasons about together) become candidate bounded contexts — the basis for service boundaries if you're heading toward microservices, or module boundaries within a modular monolith. Getting this boundary right is worth far more than getting any individual class design right, because a wrong boundary means every future change crosses it.
The Domain Discovery module in the Advanced program pairs event storming directly with the aggregate design and CQRS/command-handler prompts that follow it — the events discovered in the workshop become the domain events your aggregates actually raise in code.