Three Levels, One Method

Core Concepts

Event Storming is not a single monolithic workshop format. The methodology, originally designed by Alberto Brandolini for small collaborative groups of 6–10 participants, has since been articulated as three distinct levels of workshop, each with a different purpose, audience, and granularity.

The foundational insight is that the same notation — domain events on a shared timeline — can be applied at radically different scopes. The visual notation remains consistent across all three levels, but the scope and detail increase as teams progress deeper into analysis.

The Three Levels

Big Picture Event Storming

The widest aperture. A Big Picture session explores an entire business domain with all stakeholders present. Its goal is to create shared understanding across organizational boundaries.

Big Picture sessions naturally reveal bounded contexts through the emergence of these seams in the domain event timeline. This is one of the primary outputs and a foundational activity before any more detailed design work begins.

The session follows a proven internal progression: participants place pivotal domain events on a timeline, then identify the commands that triggered each event, and finally cluster related events and commands into groups that reveal bounded contexts. A typical full-day allocation is recommended for comprehensive discovery, with 1–2 hours for the core Big Picture pass, followed by 30-minute sessions for candidate context modeling, domain message flow, and Bounded Context Canvas work.

Process Level Event Storming

A narrower focus on a single, end-to-end business process. The participant group shrinks to 4–8 people, enabling deeper technical discussion without the coordination overhead of a large cross-functional group.

The shift in intent is equally important as the shift in group size. Process Level moves from descriptive modeling ("how things work now") to solution modeling ("how things should work"). New notation elements surface at this level: commands, read models, and business rules specific to that process.

Design Level Event Storming

The tightest focus. Design Level zooms into a single bounded context with primarily technical participants — developers — to derive a software design that can be translated directly into code.

At this level, DDD tactical patterns enter the picture: aggregates, bounded contexts, CQRS. The goal is a model with a 1:1 mapping to the codebase — something the team can implement without significant re-interpretation.

---

Compare & Contrast

	Big Picture	Process Level	Design Level
Scope	Entire business domain	Single business process	Single bounded context
Participants	All stakeholders, cross-functional	4–8 focused contributors	Primarily developers
Primary question	What happens across the domain?	How should this process work?	How do we build this?
Key outputs	Bounded context candidates, hotspots, domain map	Commands, read models, business rules	Aggregates, code-ready model
Mode	Descriptive (as-is)	Solution-oriented (to-be)	Implementable design
Typical duration	Full day	Half day	Half day to full day

How Event Storming Relates to Other Practices

Event Storming operates at the domain level, exploring broad business processes and events across systems. Example Mapping, by contrast, focuses on individual user stories at a tactical level — refining specific acceptance criteria through concrete examples. Event Storming answers "what happens in the domain"; Example Mapping answers "what does this story require."

The two practices are complementary. A bounded context identified in Big Picture Event Storming can feed into a Process Level session; the output of a Process Level session can feed into Example Mapping for a specific user story, or into a Design Level session for implementation modeling.

---

Key Principles

Match the level to the question. Choosing the wrong level wastes everyone's time. If the business question is "which areas of our domain are in trouble?", run Big Picture. If the question is "how should this checkout process work?", run Process Level. If the question is "what aggregates should back our order management service?", run Design Level.

Move through levels in sequence, not in parallel. The three levels form a natural chain: Big Picture establishes strategic context, Process Level models specific flows within that context, and Design Level produces implementation decisions within a single bounded context. Skipping levels is possible but carries risk — Design Level sessions without prior Big Picture alignment frequently model the wrong bounded context.

Keep participant groups appropriate to the level. The large, inclusive group that makes Big Picture sessions valuable is precisely what makes them unsuitable for deep technical design. The smaller group size at Process Level facilitates more detailed exploration and enables participants to develop deeper shared understanding without coordination overhead.

The model requires intentional translation. Event Storming's strength is in collaborative domain discovery and high-level business process understanding, not in producing deployment plans, UML diagrams, or system design specifications. Whatever level you run, the output must be deliberately translated into architecture, code, or documentation — it does not happen automatically.

---

Worked Example

A software team is re-platforming an e-commerce company's order management system. They know the legacy system has problems but aren't sure where the real pain is or how to slice the work.

Step 1 — Big Picture (week 1, full day)

The team convenes a cross-functional group: product managers, operations leads, customer support, fulfillment, and two senior engineers. They map domain events for the entire order lifecycle: OrderPlaced, PaymentProcessed, InventoryAllocated, ShipmentDispatched, ReturnInitiated, etc.

Clusters emerge naturally. Events around payment behavior group separately from events around warehouse operations, which group separately from events around customer communication. Boundaries between these clusters indicate where bounded contexts lie. Hotspots (red stickies marking confusion or conflict) pile up around the returns process.

Step 2 — Process Level (week 2, half day)

The returns hotspot becomes the focus. A smaller group — two engineers, a product manager, and the operations lead — maps the end-to-end returns process in detail. Commands surface: InitiateReturn, AuthorizeRefund, RestockItem. Read models appear: the customer's return status view, the warehouse queue view. Business rules become explicit: refunds over a certain threshold require manual approval.

The group is now modeling how things should work, surfacing design decisions that had been implicit in the legacy system.

Step 3 — Design Level (week 3, half day)

The engineering team takes the returns process model and runs a Design Level session. They identify two aggregates: ReturnRequest (owning the lifecycle from initiation to resolution) and RefundTransaction (owning the financial state). The bounded context boundary is now clear and defensible. The team leaves with a model they can implement.

Each level answered a different question. None of them could have answered the other levels' questions.

---

Boundary Conditions

When the domain is very large. Event Storming can become overwhelming and chaotic when applied to large, complex domains with extensive numbers of events and participants. A single Big Picture session spanning an entire enterprise is frequently too chaotic to be useful. Multiple focused sessions on specific subdomains often work better than a single large session.

When your organization operates at enterprise scale. Enterprise-scale Event Storming employs a layered approach: enterprise-level Big Picture sessions establish shared strategic context across the organization, followed by team-level Process and Design Level sessions within each bounded context. This is a meaningful extension of the original methodology. The foundational methodology assumed high synchronization among a limited set of stakeholders in a single space — it did not anticipate the coordination challenges of dozens of teams and multiple business units.

When you need technical artifacts, not shared understanding. Event Storming is the wrong tool if the deliverable is a deployment plan, a UML class diagram, or a formal architecture document. The model produced in Event Storming must be intentionally translated to architecture, code, and documentation — the workshop itself does not produce these outputs. If the stakeholder expects to walk out with those artifacts, align expectations before you book the room.

When you need acceptance criteria for a specific story. Example Mapping operates at a tactical level — individual user stories — where Event Storming cannot. If the team is ready to write tests for a single user story, Event Storming is too broad a tool. Use Example Mapping instead.