Event Storming: A Practical Guide to Understanding Complex Domains

A business process is hard to write down accurately. Interviews capture one person’s slice of it, and the specification that follows misses the steps nobody thought to mention. Event Storming closes that gap in a workshop: business experts and engineers put domain events on a wall in chronological order until the whole process is visible at once.

If you have never run one, start with the Big Picture format and keep business experts in the room for all of it. Everything else the technique offers (detailed process design, aggregate boundaries, service boundaries) rests on the shared map that first session produces, and a session without domain experts turns into a design meeting where engineers guess.

What is Event Storming

Event Storming is a workshop format created by Alberto Brandolini that brings business and technical people together to explore complex domains. The core idea is simple: map domain events (things that happen in your system) onto a timeline with sticky notes. From there the group works out the commands, actors, and business rules that drive those events.

The technique emerged from the Domain-Driven Design (DDD) community as a lightweight alternative to traditional modeling approaches. Formal diagrams and lengthy documentation give way to a long wall covered in colored sticky notes. The difference from interview-driven requirements work is that the whole group looks at the same timeline at the same time and edits it together.

What the Wall Surfaces

A well-facilitated session maps a complex business process in 2-4 hours. Assembling the same understanding from interviews and documents takes weeks. The condition is having the people who know how the business actually works in the room.

The bigger return is what shows up unasked. Business experts read the timeline and start filling holes: “Wait, what happens if the payment fails?” or “We haven’t talked about the monthly reconciliation process.” The missing pieces are obvious once the whole process is visible at once. The same effect catches mismatched mental models. When the marketing team’s “order confirmed” event sits at a different point on the wall than engineering assumed, the disagreement surfaces in the workshop and not in production.

Two side effects are worth naming. Everyone converges on the same event names, which is how a ubiquitous language (the DDD term) gets built without a glossary meeting. And the workarounds and manual steps that people have stopped noticing become visible as soon as each one needs its own sticky note.

The Color-Coding System

Event Storming uses specific colors for different types of sticky notes. The colors work as a thinking tool: each one forces a different question about the domain.

Color	What it holds	Notes
Orange	Domain events, past tense	OrderPlaced, PaymentProcessed, InventoryReserved. Facts the business cares about.
Blue	Commands, imperative	PlaceOrder, ProcessPayment, ReserveInventory. Issued by an actor or triggered by a policy.
Yellow	Actors and personas	Customer, Admin, PaymentGateway, CronJob. Humans, systems or time-based triggers.
Lilac	Policies and business rules	”When OrderPlaced, then ReserveInventory.” Connects an event to the next command.
Pink	Issues and open questions	”What happens if payment takes more than 10 minutes?” Capture and move on; don’t let it block the flow.
Green	Read models and views	AvailableInventory, CustomerCreditLimit. What an actor needs to see before issuing a command.
Large yellow	Aggregates and bounded contexts	Added in later phases. Groups of related events and commands that share a consistency boundary.

Types of Event Storming

The technique has three main types. They differ in scope, in how long they run and in who needs to be there.

Type	Goal	Duration	Who joins	Output
Big Picture	Understand the entire business domain quickly	4-8 hours	Business experts, developers, product managers	High-level event flow across the entire domain
Process Modeling	Design one business process in detail	2-4 hours	Smaller group focused on that process	Detailed process flow with all edge cases
Software Design	Translate the domain model into architecture	2-4 hours	Mostly developers, some business experts	Aggregates, bounded contexts, integration points

Big Picture Event Storming

This is where you start. The scope is everything that happens in the business domain, from customer signup to order fulfillment to monthly reporting, and the depth belongs to the other two formats.

The running order is:

1. Domain events in rough chronological order
2. Actors and commands
3. Hotspots (areas with lots of questions or complexity)
4. Related events grouped into subdomains

New projects and legacy systems benefit most. So does onboarding, and so does the exploration before an acquisition or a large integration, where nobody in the room has the full picture yet.

Process Modeling Event Storming

Now you pick one process (“order checkout”, “customer onboarding”) and go deep. Every edge case and every error path matters here, and a process that looked simple almost always turns out to have cases nobody wrote into the requirements. You add the business rules and policies, work out which read models the actors need, map the compensating actions for each failure, and settle where the consistency boundaries fall.

Software Design Event Storming

Of the three formats this one is the most technical, and it leans on the other two, which have already established what the domain does. Events and commands get grouped into aggregates, bounded contexts get their boundaries, integration points get anti-corruption layers, and transaction scopes get decided.

How to Run an Event Storming Session

Here’s a step-by-step approach that works in practice:

Before the Session

In person, the constraint is wall length: a big picture session wants 5-10 meters of clear surface, with nothing else on it competing for attention. Buy more sticky notes than you think you need and bring thick markers, because thin ones are unreadable from two steps back. Remote, the constraint is tooling: a digital whiteboard (Miro, Mural or FigJam), a board template with color-coded areas prepared in advance, a dry run with participants, and a longer schedule, since remote sessions move slower.

The invite list matters more than either. You need business experts who know how things actually work (not how they should work), the developers who will build the system, a product owner, and domain experts for the specific areas in scope. Aim for 6-12 people: smaller and you miss perspectives, larger and facilitation becomes difficult. Send them a short note beforehand explaining what Event Storming is, why you are running one, and what to bring. Say clearly that the session is exploratory and that no “right” answer exists yet, otherwise people arrive expecting to sign off on a design.

During the Session

Phase 1: Domain Events (45-60 minutes)

Start with this instruction: “Write down events - things that happen in our domain that the business cares about. Use past tense. Put them on the wall in rough chronological order.”

Let people work silently for 10-15 minutes first. This generates a lot of events quickly and prevents one person from dominating.

Then walk through the timeline together. As you go:

• Group duplicate events
• Clarify ambiguous names
• Don’t debate - if there’s disagreement, put both versions up
• Use pink stickies for questions that come up

Common gotcha: people will want to jump to solutions. Keep asking what happens today; the redesign can wait until the current process is on the wall.

Phase 2: Commands and Actors (30-45 minutes)

Now add blue stickies for commands before each event: “What action caused this event to happen?”

Add yellow stickies for actors: “Who or what triggered this command?”

This is where the model starts to feel real. You’ll see patterns emerge:

• External actors (customers, partners)
• Internal actors (admins, support staff)
• System actors (schedulers, integrations)

Phase 3: Policies and Business Rules (30-45 minutes)

Look for automatic reactions: “When X happens, then Y must happen.” Use lilac stickies to connect events to commands, one sticky per rule. A typical one reads “When PaymentReceived, then SendConfirmationEmail and UpdateInventory”.

Phase 4: Questions and Hotspots (20-30 minutes)

Step back and look at the wall. Where are the clusters of pink stickies? A cluster usually marks complexity, an integration point with another system, or a place where the requirements were never clear. Nothing here has to be answered inside the session. What matters is leaving with a ranked list of the clusters worth a deeper look.

Phase 5: Next Steps (15 minutes)

Close by agreeing which processes need deeper modeling and who writes up the findings, then set the date for the next session.

After the Session

Photograph the wall in high resolution from several angles before anyone leaves the room, because the notes come loose and go missing once the room is cleared.

Then write up the workflows the group discovered, the open questions with an owner attached to each, the decisions made, and the hotspots that need attention. Skip the full transcription. The conversation carries the value, and a perfect record of every sticky note adds little once the group has moved on. Share the photos and the summary within a week and book the deeper dives while the session is still fresh.

Remote Event Storming

Remote sessions work, with adjustments in three places.

The board needs preparation the wall doesn’t: frames or sections for the timeline, a palette of pre-colored sticky note templates, a parking lot area for questions, and cursor tracking turned on so people can see where others are working.

Facilitation gets more deliberate. Say whose turn it is to talk, run the built-in timer so phases end on time, check in more often (“Does this make sense to everyone?”) and record the session for people who couldn’t attend. Breaks come more frequently than in person. Breakout rooms are useful for small-group work as long as the groups merge back and each person walks the others through their stickies out loud.

Some things improve. Silent brainstorming is better remotely because nobody is queueing for wall space, patterns can be duplicated across the board in a click, and people can work asynchronously on separate areas. What you lose is the energy in the room and the side conversations that happen next to the wall.

Facilitation Habits and Naming Traps

Keeping the Wall Moving

Get the happy path down first and add edge cases afterwards. A session that opens with “what if the payment gateway is down?” never reaches the main flow. Use real scenarios while you do it: “yesterday’s order #12345” is something people can argue about, “an order” is not.

Conflict is useful here. When two people describe the same process differently, both versions go on the wall, because the gap between them is information. Pink stickies serve the same purpose for open questions: the question stays parked on the wall until someone can look at it properly, and the timeline keeps moving. Set a timer for each phase too. You can always extend it, and the limit stops the group from perfecting event names. “OrderSubmitted” versus “OrderPlaced” does not matter yet, so one of them goes up and the name can change later.

The two habits that sink sessions are early implementation talk and an absent facilitator. “We’ll use Kafka” and “this should be microservices” are fine conversations for another day, and someone has to own the clock, redirect the discussion and pull in the quiet participants. That person cannot also participate fully.

Where Event Names Go Wrong

Event Granularity: Is “OrderProcessed” one event or six? It depends. If the business cares about each step separately, split it. If they only care about the outcome, keep it as one.

CRUD vs Events: “OrderUpdated” isn’t usually a good domain event. What actually changed? “ShippingAddressChanged”, “OrderCancelled” - these are meaningful events.

Technical Events: Be careful about including technical events like “EmailQueued” or “CacheInvalidated”. Focus on business events first. Technical events come later in software design sessions.

Past vs Future: Events are past tense (already happened). Commands are imperative (make it happen). This distinction helps keep the model clear.

Where a Session Pays Off

The clearest case is a new project, where a few hours on the wall before the first line of code saves weeks of rework later. Close behind is the inherited system nobody fully understands: invite the people who have been there longest and let the timeline rebuild the knowledge that never got written down. New joiners pick up a domain faster from one session than from a folder of documentation, which makes onboarding a good excuse to run one even when the domain is stable.

Two architectural decisions lean on it as well. Service boundaries follow the bounded contexts and aggregates on the wall, so drawing them before the domain is understood is guesswork. Integration work is the same problem in miniature: storm the integration points with the other team, and you leave with the list of events the two systems have to exchange.

Process redesign has its own sequence. Storm the current state first and the desired state second, because the differences between the two walls are the actual scope of the change.

From Sticky Notes to Code

Here’s how Event Storming artifacts map to implementation:

Domain Events → Event Classes

// Orange sticky note: "OrderPlaced"
interface OrderPlacedEvent {
  eventId: string;
  orderId: string;
  customerId: string;
  items: OrderItem[];
  totalAmount: number;
  placedAt: Date;
}

Commands → Command Handlers

// Blue sticky note: "PlaceOrder"
class PlaceOrderCommand {
  constructor(
    public customerId: string,
    public items: OrderItem[],
  ) {}
}

class OrderCommandHandler {
  async handle(command: PlaceOrderCommand): Promise<OrderPlacedEvent> {
    // Validate command
    // Apply business rules
    // Create event
    // Persist and publish
  }
}

Policies → Event Handlers

// Lilac sticky note: "When OrderPlaced, then ReserveInventory"
class InventoryPolicy {
  @EventHandler(OrderPlacedEvent)
  async onOrderPlaced(event: OrderPlacedEvent): Promise<void> {
    const command = new ReserveInventoryCommand(
      event.orderId,
      event.items
    );
    await this.commandBus.send(command);
  }
}

Aggregates → Aggregate Root Classes

// Large yellow sticky grouping Order-related events
class Order {
  private id: string;
  private status: OrderStatus;
  private items: OrderItem[];

  place(customerId: string, items: OrderItem[]): OrderPlacedEvent {
    // Business logic
    // Validate
    // Create event
  }

  cancel(reason: string): OrderCancelledEvent {
    if (this.status === 'shipped') {
      throw new Error('Cannot cancel shipped order');
    }
    // Create event
  }
}

The mapping is not mechanical. Names get revised once they become types, and a few events end up merged into one class. The model you start coding against is still the one the business described at the wall.

When the Default Holds

The Big Picture default holds whenever the domain is unfamiliar and the people who understand it can be in the room. A long wall and a few hours with 6 to 12 participants will get you further than another round of written requirements.

Override it when the workflow is already stable and well understood, when the application is CRUD with no interesting rules, or when the business experts cannot attend. Without them the wall fills with assumptions that nobody present can confirm, and you are back to guessing. For a first attempt, scope the session to a single process and invite the people who run it day to day.

References

• Introducing EventStorming by Alberto Brandolini - The definitive book on Event Storming by its creator, covering Big Picture, Process Design, and Software Design formats.
• EventStorming.com - Alberto Brandolini’s official Event Storming website with resources, articles, and community links.
• EventStorming Book - Official Page - The official book page with background on the methodology and its evolution since 2013.
• DDD Reference by Eric Evans - Free reference guide summarizing all patterns from Eric Evans’ Domain-Driven Design book, the conceptual foundation for Event Storming.
• Domain-Driven Design Community - The DDD community resource for Eric Evans’ original book, relevant to understanding the DDD context in which Event Storming operates.