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. Instead of formal diagrams and lengthy documentation, you get a room full of people, a long wall, and lots of colorful sticky notes.

Here’s what makes it different from traditional requirements gathering:

• Visualization: Everything goes on the wall in a spatial timeline
• Collaboration: Business experts and developers work together in real-time
• Speed: A few hours of workshop replace weeks of interviews
• Shared language: The process builds a common vocabulary naturally

Why Event Storming Works

Event Storming is valuable in several specific ways that traditional requirements sessions miss:

Faster Domain Understanding: In a well-facilitated session, you can map out a complex business process in 2-4 hours that would take weeks through interviews and documentation. The key is having the right people in the room - those who know how the business actually works.

Uncovering Hidden Requirements: When business experts see the timeline on the wall, they spot gaps. “Wait, what happens if the payment fails?” or “We haven’t talked about the monthly reconciliation process.” These questions emerge naturally because the visualization makes the missing pieces obvious.

Team Alignment: Developers and business people often have different mental models of the same process. Event Storming makes those differences visible immediately. When the marketing team’s “order confirmed” event happens at a different point than what engineering assumes, the mismatch surfaces in the workshop instead of in production.

Shared Language: The process naturally builds a ubiquitous language (in DDD terms). When everyone uses the same event names and agrees on what they mean, you avoid the translation layer that usually exists between business and tech.

The knock-on effects show up quickly:

• You discover edge cases early, when they’re cheap to handle
• Business experts feel heard because their knowledge is literally on the wall
• Technical debt becomes visible when you see workarounds and manual steps
• The timeline reveals bottlenecks and opportunities for automation

A recurring pattern: business experts know more than they realize. The workshop format lets them externalize that knowledge in a way that interviews don’t.

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.

Orange - Domain Events (past tense): Things that have happened

• OrderPlaced, PaymentProcessed, InventoryReserved
• These are facts that the business cares about
• Always written in past tense

Blue - Commands (imperative): Actions that cause events

• PlaceOrder, ProcessPayment, ReserveInventory
• Usually triggered by actors or other events
• Written as actions

Yellow - Actors/Personas: Who or what triggers commands

• Customer, Admin, PaymentGateway, CronJob
• Can be humans, systems, or time-based triggers

Lilac/Purple - Policies/Business Rules: Automated reactions

• “When OrderPlaced, then ReserveInventory”
• These become event handlers in your code
• Connect events to commands

Pink - Issues/Questions: Things to resolve later

• “What happens if payment takes more than 10 minutes?”
• “Do we need to handle partial refunds?”
• Don’t let these block the flow - capture and move on

Green - Read Models/Views: Information needed to make decisions

• AvailableInventory, CustomerCreditLimit
• What data do actors need to see before issuing commands?

Large Yellow - Aggregates/Bounded Contexts (later phases)

• Groups of related events and commands
• Natural consistency boundaries in your system

Types of Event Storming

There are three main types, each with different goals and levels of detail:

Big Picture Event Storming

Goal: Understand the entire business domain quickly Duration: 4-8 hours Participants: Wide range - business experts, developers, product managers Output: High-level event flow across the entire domain

This is where you start. You’re mapping out everything that happens in your business domain, from customer signup to order fulfillment to monthly reporting. The focus is breadth, not depth.

What to do:

1. Start with domain events in rough chronological order
2. Add actors and commands
3. Identify hotspots (areas with lots of questions or complexity)
4. Group related events into subdomains
5. Don’t dive into details yet - stay high level

This works well when:

• Starting a new project or product
• Onboarding new team members
• Understanding a legacy system nobody fully understands
• Exploring a potential acquisition or integration

Process Modeling Event Storming

Goal: Design a specific business process in detail Duration: 2-4 hours Participants: Smaller group focused on one process Output: Detailed process flow with all edge cases

After the big picture session, you pick a specific process (like “order checkout” or “customer onboarding”) and dive deep. Now you care about every edge case, every validation, every error scenario.

What to do:

1. Take one process from the big picture
2. Add all the business rules and policies
3. Identify all the read models needed
4. Map out error scenarios and compensating actions
5. Define boundaries and consistency requirements

This is where you discover that “simple” processes have 15 edge cases nobody mentioned in the requirements.

Software Design Event Storming

Goal: Translate domain model into software architecture Duration: 2-4 hours Participants: Mostly developers, some business experts Output: Aggregates, bounded contexts, integration points

This is the most technical type. You’re deciding how to implement what you discovered in the process modeling session.

What to do:

1. Group events and commands into aggregates
2. Define bounded contexts and their boundaries
3. Identify integration points and anti-corruption layers
4. Map out event flows between contexts
5. Decide on consistency boundaries and transaction scopes

Skipping straight to this phase without big picture or process modeling usually ends badly. The domain understanding must come first.

How to Run an Event Storming Session

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

Before the Session

1. Prepare the Space

For in-person:

• Find the longest wall you can (you’ll need 5-10 meters for a big picture session)
• Get lots of sticky notes in the right colors (buy more than you think you need)
• Bring thick markers (thin ones are hard to read from a distance)
• Clear the wall - you want nothing else competing for attention

For remote:

• Use a digital whiteboard (Miro, Mural, or FigJam work well)
• Set up the board template with color-coded sticky note areas
• Test the tools with participants beforehand
• Plan for longer sessions (remote is slower)

2. Invite the Right People

You need:

• Business experts who know how things actually work (not how they should work)
• Developers who will build the system
• Product owner or manager
• Domain experts for specific areas

Aim for 6-12 people. Smaller and you miss perspectives. Larger and facilitation becomes difficult.

3. Set Expectations

Send a brief explanation beforehand:

• What Event Storming is
• Why you’re doing it
• What participants should bring (domain knowledge, questions)
• That it’s exploratory - there’s no “right” answer yet

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. These are your event handlers, your business logic, your automation opportunities.

Example: “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? Where do people have the most questions?

These hotspots are either:

• Areas of complexity you need to focus on
• Gaps in your current understanding
• Integration points with other systems
• Places where requirements are unclear

Don’t try to answer everything now. Prioritize what to explore deeper.

Phase 5: Next Steps (15 minutes)

Decide as a group:

• Which processes need deeper modeling
• Who will document the findings
• What questions need research
• When to meet again

After the Session

Take Photos: Get high-resolution photos of the entire wall from multiple angles. The sticky notes will fall off, get lost, or fade.

Document Key Insights: Write up:

• Major workflows discovered
• Open questions and who owns them
• Decisions made
• Hotspots that need attention

Don’t Transcribe Everything: The conversation carries the value. A perfect record of every sticky note adds little once the group has moved on.

Follow Up: Within a week, share photos and summary. Schedule deeper dives on specific processes.

Remote Event Storming

Remote sessions work, but they require adjustments:

Tool Setup

• Use frames or sections to organize the timeline
• Create a palette of pre-colored sticky note templates
• Have a parking lot area for questions and issues
• Enable real-time cursor tracking so people can see what others are doing

Facilitation Adjustments

• Be more explicit about whose turn it is to talk
• Use the timer feature to keep phases moving
• Do more frequent check-ins (“Does this make sense to everyone?”)
• Record the session if possible for people who couldn’t attend

Engagement Techniques

• Use breakout rooms for small group work, then merge back
• Have everyone verbally walk through their sticky notes
• Use voting/reactions to build consensus
• Take breaks more frequently (remote fatigue is real)

What Works Differently

• Silent brainstorming works better remotely (no wall space limitations)
• You can easily copy/duplicate patterns across the board
• People can work asynchronously on different areas
• But you lose some of the energy and spontaneous conversation

Common Patterns and Pitfalls

What Works

Start with Happy Path: Get the main flow down first, then add edge cases. If you start with “what if the payment gateway is down?”, you’ll never finish.

Use Real Examples: Instead of abstract events, use actual business scenarios. “Yesterday’s order #12345” is more concrete than “an order.”

Embrace Conflicts: When two people have different views of the same process, put both on the wall. The differences are valuable information.

Capture, Don’t Solve: Pink stickies exist to park an issue until someone can look at it properly. Keep moving.

Timebox Phases: Set a timer for each phase. You can always extend it, but having a time limit keeps things moving.

What Doesn’t Work

Analysis Paralysis: Don’t try to perfect every event name. “OrderSubmitted” vs “OrderPlaced” doesn’t matter yet. Pick one, move on, refactor later if needed.

Implementation Talk Too Early: Keep the conversation at the business level initially. “We’ll use Kafka” or “This should be microservices” can wait.

Skipping the Big Picture: Teams want to dive into detailed process modeling immediately. Resist. You need context first.

Not Involving Business Experts: An Event Storming session with only developers is just a design session. You need the people who know the domain.

No Facilitator: Someone needs to own the process, keep time, redirect conversations, and ensure everyone participates. Don’t try to facilitate and participate fully at the same time.

Typical Gotchas

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.

When to Use Event Storming

Event Storming is particularly useful in these scenarios:

Starting a New Project: Before writing code, understand the domain. A good Event Storming session can save weeks of rework.

Legacy System Understanding: When you inherit a system nobody fully understands, Event Storming helps rebuild that knowledge. Invite people who’ve been there longest.

Team Onboarding: New team members get up to speed much faster by participating in an Event Storming session than by reading documentation.

Process Redesign: When the business wants to change how something works, Event Storm the current state first, then the desired state.

Microservices Boundaries: The bounded contexts and aggregates you discover naturally suggest service boundaries. Don’t draw microservices lines without understanding the domain first.

Integration Planning: When you need to integrate with another system or team, Event Storm the integration points to understand what events you need to exchange.

When Not to Use It:

• Simple CRUD applications with obvious workflows
• When you can’t get business experts in the room (you’ll just guess)
• Projects with well-understood, stable domains (unless onboarding)
• Very early exploration before you even know what problem you’re solving

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
  }
}

This mapping isn’t automatic, but Event Storming gives you a head start on your domain model that’s grounded in how the business actually works.

Conclusion

Event Storming looks simple and takes practice to facilitate well. The Big Picture default holds whenever the domain is unfamiliar and the people who understand it can be in the room: a long wall, a few hours, and 6 to 12 participants get you further than another round of written requirements.

Override that default 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 in the room can confirm.

For a first attempt, take one process instead of the whole domain, invite the people who run it day to day, and timebox each phase. Even an imperfect session usually surfaces a question nobody had thought to ask.

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.