Event Storming in Practice

This is the first deep-dive in a series on Domain-Driven Design. It builds on the concepts introduced in Domain-Driven Design: A Practical Overview.

What Event Storming Is

Event Storming is a collaborative workshop technique created by Alberto Brandolini. It brings together developers, domain experts, product people, and anyone else with knowledge of how the business works. The goal is to explore a business process by focusing on what happens, domain events, before worrying about how to implement anything.

The output is not a requirements document. It’s a shared mental model of the domain, surfaced through conversation and captured visually on a wall (or a digital board). That shared understanding is the real deliverable. The sticky notes are just a record of it.

Why Events First

Most discovery approaches start with nouns: what are the entities, what are the data fields, what does the database look like. Event Storming starts with verbs. What happened?

This matters because business processes are sequences of things happening. An order was placed. A payment was received. A shipment was dispatched. Starting with events forces the conversation toward behavior and away from premature data modeling.

Events also expose the boundaries in a system. When the language shifts, when “order” means something different to the warehouse team than it does to the billing team, you’re looking at a bounded context boundary. Those boundaries are hard to find by staring at an ER diagram. They surface naturally when you’re walking through what happens.

The Sticky Notes

Event Storming uses a color-coded system of sticky notes. Each color represents a different concept:

Orange: Domain Events. The core of the exercise. Things that happened in the domain, written in past tense. “Order Placed.” “Payment Received.” “Shipment Dispatched.” These go up first and everything else builds around them.

Blue: Commands. The actions that cause events. Written as imperatives. “Place Order.” “Process Payment.” These answer the question: what triggered this event?

Yellow: Actors. The people or roles that issue commands. “Customer.” “Warehouse Manager.” “Support Agent.” Not every command comes from a person. Some are triggered by policies or external systems.

Purple: Policies. Automated reactions. “When payment is received, reserve inventory.” Policies connect events to commands, revealing the automation rules that drive the business. These are some of the most valuable discoveries in a session because they’re often undocumented.

Green: Read Models. The information an actor needs to make a decision or issue a command. “Order Summary.” “Inventory Dashboard.” These surface UI and reporting requirements organically.

Pink: External Systems. Systems outside your control that either trigger events or receive commands. “Payment Gateway.” “Shipping Provider.”

Red: Hot Spots. Questions, disagreements, pain points, unknowns. These are the most important stickies on the board. A cluster of hot spots tells you where the domain is complex, where the team disagrees, or where institutional knowledge is missing.

Running a Session

Before the Workshop

Keep preparation minimal. You need a long wall (or a large digital board), sticky notes in the right colors, markers, and the right people in the room. The “right people” means anyone who understands how the business process works. Not just developers, not just managers.

Set a timebox. Two to three hours for a focused process. A full day for a big-picture exploration. Shorter is better when you’re starting out.

Phase 1: Event Discovery

Start with one instruction: write down the things that happen in this process as domain events. Orange stickies. Past tense. One event per sticky.

Don’t worry about order. Don’t debate. Just get events on the board. Encourage duplicates. If two people write “Order Shipped” and “Shipment Dispatched,” that’s a conversation worth having later. Resist the urge to organize too early. The mess is the point.

This phase is chaotic by design. People will disagree about what happens, when it happens, and what to call it. That disagreement is information. Let it surface.

Phase 2: Establish a Timeline

Once the events slow down, start arranging them left to right in rough chronological order. This is where the real conversations start. Gaps appear. “Wait, what happens between payment and shipping?” Contradictions surface. “I thought we verify inventory before charging the card.” Missing events get added.

The timeline doesn’t need to be perfect. It needs to be good enough that the group can walk through the process from left to right and agree on the major beats.

Phase 3: Commands and Actors

Now enrich the board. For each event, ask: what caused this? Add blue command stickies. Who or what initiated it? Add yellow actor stickies.

This phase reveals agency. Some events are caused by user actions, some by automated policies, some by external systems. The distinction matters for system design and it matters for understanding where responsibility lives in the organization.

Phase 4: Policies and Read Models

Add purple stickies for automation rules, the “whenever X happens, do Y” logic that connects events to subsequent commands. These are often the most valuable discoveries because they expose business rules that live in people’s heads rather than in documentation.

Add green stickies for the information actors need to make decisions. What does the warehouse manager look at before approving a shipment? What does the customer see after placing an order?

Phase 5: Hot Spots

Throughout the session, encourage people to throw down red hot spot stickies whenever something is unclear, contested, or painful. At this point, review them explicitly. Cluster them. Some will resolve through conversation. Others will become work items, research tasks, or inputs into design decisions.

Hot spots near domain boundaries are valuable. They often indicate where bounded contexts need clear contracts or where integration patterns matter most.

From Stickies to Models

An event storming board is not a domain model. It’s the raw material for one. The translation step is where engineering judgment enters.

Finding Bounded Contexts

Look for clusters of events that share language and cohesion. When the same word means different things in different clusters, “order” in fulfillment vs. “order” in billing, you’re likely looking at separate bounded contexts. The boundaries often align with organizational boundaries, which is not a coincidence.

Identifying Aggregates

Commands that enforce business rules before producing events point toward aggregates. If “Place Order” needs to verify inventory, validate the customer, and calculate pricing before producing “Order Placed,” that cluster of rules and the data they protect is an aggregate. The aggregate is the consistency boundary, the thing that says “these rules must all hold true together.”

Extracting Domain Events

The orange stickies become your domain events, but they’ll need refinement. Workshop events are conversational. “Order Placed” becomes OrderPlacedEvent with specific properties: OrderId, CustomerId, OrderTotal, PlacedAt. The important thing is that the names carry over from the workshop into the code. That’s the ubiquitous language at work.

Spotting Policies as Domain Logic

Purple stickies often translate directly into domain services or event handlers. “When payment is confirmed, reserve inventory” becomes an event handler that listens for PaymentConfirmedEvent and issues a ReserveInventoryCommand. These are the workflows that connect bounded contexts.

Common Mistakes

Over-organizing too early. The first 30 minutes should be messy. If people are debating sticky placement instead of generating events, you’re optimizing too soon.

Missing the right people. A room full of developers will model what they think the business does, not what it actually does. Domain experts are not optional.

Treating it as a one-time exercise. Event Storming is most valuable as a recurring practice. Run it when starting a new feature, when onboarding a team, when something feels wrong. The model evolves with the business.

Jumping to implementation. The board is not a system design. It’s an input to system design. Resist the temptation to start drawing service boundaries and database schemas during the workshop.

Ignoring hot spots. Red stickies are not noise. They’re signal. A hot spot that nobody can resolve is telling you something important about the domain’s complexity or the organization’s understanding of it.

Tools

Event Storming was designed for physical walls with real sticky notes. There’s something about the physicality, standing up, moving things around, clustering, that helps with engagement and spatial thinking.

For remote or distributed teams, digital tools work. Miro is popular. I built StormBoard for this. It enforces the phased approach, the color scheme, and includes AI-assisted facilitation that can spot missing events, suggest patterns, and help translate the board into DDD artifacts.

Whatever tool you use, the tool is secondary to the conversation it enables.

What Comes Next

Event Storming gives you the raw material. The next steps, establishing ubiquitous language, defining bounded contexts, modeling aggregates, are where that material becomes a domain model. Those topics are covered in upcoming posts in this series.

If you haven’t tried Event Storming, start small. Pick a single business process your team is about to build or modify. Get the right people in a room for two hours. Put orange stickies on a wall. The conversations that follow will be more valuable than any requirements document.