Event Storming

A collaborative workshop technique for exploring complex business domains through domain events.

Event Storming is a workshop where people with questions (often developers) meet people with answers (often stakeholders) to explore a business domain together. The focus is on domain events, instead of data models or code.

Participants write domain events on sticky notes and arrange them on a timeline. An event describes something that happened in the business: "Order Placed", "Payment Received", "Shipment Dispatched", etc. From there, you discover other parts of the system like commands (what triggers events), aggregates, and policies (automated reactions to events).

Event Storming works well because it makes everyone understand the domain the same way. Business people don't need to learn UML, and developers don't need to guess how things work. Everyone works with the same simple format of sticky notes on a wall.

Event Storming runs at two main levels. Pick the level based on what you're trying to learn. You can use Big Picture Event Storming to map an entire business process at a high level, or Process Level Event Storming to dive into the details of a specific feature or aggregate. The output can be translated into code.

Notation

Different levels of Event Storming use different sets of sticky notes. Most newcomers start with one color and add more as the conversation gets concrete.

Big Picture Event Storming: events only

• Orange: Domain events. Something that happened in the system, named in past tense ("Order Placed", "Payment Received").

That's enough for most discovery sessions. The whole story fits on a wall of orange.

Process Level Event Storming: the full palette

Once you zoom in on a specific area, more notes show up around each event. Reading the board is like reading a sentence: an actor sends a command to an aggregate, which produces an event.

• Red: Hotspots. Disagreements or open questions, parked for later.
• Blue: Commands. Entry points that ask the system to do something ("Place Order"). Verbs in imperative form.
• Small yellow: Actors. The person or system triggering the command.
• White: Inputs or notes. Data passed to a command, or open questions and assumptions captured during the session.
• Green: Views / Read Models. Information shown to users, or data a command consults to make a decision.
• Pink: External systems. Services outside the boundary you're modeling.
• Yellow: Aggregates. The entities that own consistency for the surrounding commands and events.
• Lilac: Policies. Automated reactions: "whenever X happens, do Y."

You don't need to memorize every color. Most of the value comes from the events alone. The other notes show up as the conversation gets more detailed.

It is one of the most practical techniques for discovering what to build before you build it.