Skip to content
~/sph.sh

Event Storming: A Practical Guide to Understanding Complex Domains

A hands-on guide to Event Storming - what it is, how to facilitate sessions effectively, and when to use this collaborative workshop technique for domain modeling and system design.

Abstract

Event Storming is a collaborative workshop technique that helps teams quickly understand complex business domains and workflows. This guide shares practical insights from facilitating Event Storming sessions - covering what it is, why it works, how to run effective sessions, and when to use it. You'll learn the color-coding system, facilitation techniques that work in practice, and how to handle both in-person and remote sessions.

What is Event Storming

Event Storming is a workshop format created by Alberto Brandolini that brings together business and technical people to explore complex business domains. The core idea is simple: use sticky notes to map out domain events (things that happen in your system) on a timeline, then collaboratively discover 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: You can model complex domains in hours, not weeks
  • Shared language: The process builds a common vocabulary naturally

Why Event Storming Works

I've found Event Storming 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, you find out in the workshop, not 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.

Here's what works in practice:

  • 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

One pattern I've seen repeatedly: the business experts know more than they realize they know. 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. This isn't just aesthetics - the colors help you think about different aspects of 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

I've found 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

Working with teams taught me that skipping straight to this phase without big picture or process modeling usually ends badly. You need the domain understanding 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 bringing them back to "what happens" not "what should happen."

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 value is in the conversation that happened, not in having a perfect record of every sticky note.

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

I've found remote sessions need about 30% more time than in-person for the same scope.

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 for questions are there to capture issues, not solve them in the moment. 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

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

Commands → Command Handlers

typescript
// 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

typescript
// 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

typescript
// Large yellow sticky grouping Order-related eventsclass 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 is one of those techniques that seems simple but takes practice to facilitate well. The core insight - that bringing people together around a visual timeline accelerates understanding - holds up across different domains and team structures.

Here's what works in practice:

  • Start with big picture before diving into details
  • Keep the business experts involved throughout
  • Use the color-coding system consistently
  • Timebox phases to maintain momentum
  • Don't try to solve every question in the moment
  • Take good photos and document key insights quickly

The real value isn't the sticky notes on the wall. It's the shared understanding that develops when business and technical people explore a domain together. That shared understanding shows up in better design decisions, fewer misunderstandings, and code that reflects how the business actually works.

If you're planning your first Event Storming session, start small. Pick one process, gather the right people, get the materials ready, and facilitate the conversation. The technique is forgiving - even an imperfect session will teach you something valuable about your domain.

Further Resources

References

domain-driven-design
event-storming
software-architecture
agile-practices
team-collaboration

Related Posts