A system of concepts is the foundation of a domain model. But there's an awkward question: how do you obtain it? Domain knowledge is smeared across heads: sales know their part, the warehouse theirs, accounting theirs — and nobody sees the process end to end. Classic one-on-one interviews are a telephone game in slow motion. Event Storming solves the problem differently: gather everyone in one room and, in a few hours, lay the process out on a wall. All of it.

The idea: events as a common language

Why is the technique built around domain events ("order placed," "payment received," "goods shipped")? Because an event is the one form of knowledge everyone finds easy to talk about:

  • the business already thinks this way — "first a request comes in, then we check it…";
  • an event is a fact in the past tense: people don't argue "how it should be" — they recall "how it happens";
  • events have a natural axis — time: they can be laid out chronologically, and the gaps become visible to the naked eye.

No UML, no notations the business can't read. An orange sticky + past tense + a wall. The entry barrier is zero, so the experts participate instead of merely attending.

How the storm goes: from chaos to structure

1. Event dump. All participants (domain experts + engineers, usually 6–10 people) silently write the events of their slice of the process on orange stickies and put them on a long paper roll on the wall. No discussion at this stage — the point is to unload. Chaos is normal.

2. Timeline. Together, arrange the events in time: what follows what. The main things surface immediately: duplicates under different names ("request accepted" vs "order created" — one event or two?), holes ("what happens between payment and shipping?"), and branches.

3. Hot spots. Wherever participants start arguing or nobody knows the answer, a pink/red sticky goes up — a hot spot. This is the gold of the workshop: every such sticky is either a hidden concept conflict or a process hole you'd otherwise discover in production.

4. Commands and actors. Causes are added to the events: a command (a blue sticky — "place the order") and who issues it (an actor) or what triggers it (a policy-reaction: "whenever a payment is received — reserve the goods"). A chain emerges: command → event → policy → command → …

5. Aggregates and contexts. Now you can see what the commands and events cluster around — those clumps are the candidate aggregates (yellow stickies): the "Order" accepts "place," "cancel" and emits the corresponding events. And where the language changes along the roll ("order" becomes "shipment," "customer" becomes "recipient"), a context boundary shows through — the same strategic one, only discovered on the real process rather than in a meeting room.

The result of a few hours: an event timeline, a map of hot spots, aggregate candidates and context boundaries. That is the extracted ontology — the raw material for the domain model and the spec.

Practice: what you need and where it breaks

What you need: a long wall with paper (or an infinite board in Miro for distributed teams), plenty of stickies in three or four colors, a facilitator and — critically — live domain experts, not their representatives. Pick the depth to match the task: big picture (the whole business process, 2–4 hours) or a process/design-level session for a chosen slice.

Where it breaks:

  • The facilitator dictates. If an engineer writes the stickies "as understood," you get an interview with decorations. The experts write.
  • Arguing about "correct" instead of "how it happens." Events are facts; if an argument drags on, that's a hot spot — mark it and move on, don't drown.
  • Jumping to solutions. "We need Kafka here" in hour two is premature: right now you're extracting concepts; technology comes later.
  • One and done. The storm isn't a project kickoff ceremony but a tool: the process changed — the wall gets rebuilt.

In short

  • Event Storming is a workshop where experts and engineers lay the domain out on a wall as event stickies in a timeline; events are chosen because facts in the past tense are easy for everyone to discuss.
  • The flow: event dump → timeline → hot spots (arguments and holes — the main value) → commands, actors, policies → aggregate candidates and context boundaries (where the language changes).
  • The output is an extracted system of concepts: raw material for the domain model, the spec and the tactical patterns.
  • The rules: experts write, not the facilitator; arguments get marked, not settled on the spot; technology comes later; the wall lives with the process.