EventStorming: Big-Picture, Process, and Software Design Levels

What This Concept Is

EventStorming (Alberto Brandolini, 2013) is a workshop technique for exploring a business domain by mapping domain events on a long paper roll or a virtual board using a specific color legend of sticky notes. It is the fastest way to uncover boundaries, discover hidden flows, and surface disagreements between domain experts.

It comes in three levels of resolution:

1. Big-Picture EventStorming -- whole business, few hours, wide audience. Goal: see the elephant, spot the obvious misalignments, identify candidate subdomains.
2. Process-Level EventStorming -- one process (e.g., "book a parcel"), half-day to day. Goal: trace the process end to end, surface policies, hotspots, external systems, candidate bounded contexts.
3. Software/Design-Level EventStorming -- single context, half-day. Goal: sketch the aggregates, commands, and read models that implement the process. Feeds directly into tactical modeling.

The sticky-note color legend

Color	Shape	What it is	Example
Orange	rectangle	Domain event -- past-tense fact, "something happened"	ShipmentBooked
Blue	rectangle	Command -- an intention, "somebody wants X to happen"	BookShipment
Yellow (small)	rectangle	Actor / Persona -- who issues the command	Dispatcher
Pink	rectangle	External system	Carrier Gateway, Stripe
Lilac / Purple	rectangle	Policy -- reactive logic "whenever X happens, do Y"	Whenever ShipmentBooked, assign carrier
Green	rectangle	Read Model -- information someone needs to make a decision	Carrier Capacity Dashboard
Yellow (large)	rectangle	Aggregate -- added in software-design phase	Shipment, Invoice
Red (hot-spot)	any	Problem, question, disagreement	Who owns cancellations?

Layout convention: time flows left to right. Orange events are placed on a single horizontal timeline. Commands sit immediately to the left of the event they produce. Actors sit above commands. Policies hang below the timeline and link earlier events to later commands.

Why It Matters Here

EventStorming is how you discover bounded context candidates before writing code. Trying to design aggregates and contexts without first mapping the event flow is how teams end up with boundaries that cut across natural process seams. Two properties make it powerful:

• It privileges the language of change. Events force past-tense, business-meaningful names. "Shipment was booked" is clearer than "shipment service call succeeded."
• It makes disagreement visible. Two experts slap contradictory events onto the timeline, a red hotspot goes up, and the real conversation starts.

A well-run big-picture session often collapses four months of "we'll get to that in design review" into one morning.

Concrete Example

Case: Parcel Shipping Co. -- Big-Picture session transcript (excerpt)

Fifteen people in a room: four dispatchers, two support agents, three engineers from Shipping and Tracking, one pricing analyst, one carrier integrations engineer, one finance person, one product manager, one facilitator. No laptops.

After 30 minutes of chaos-writing orange events, the timeline contains ~60 events. After grouping and ordering another 40 minutes later, a segment reads left-to-right:

-- Sales --        -- Booking / Shipping --        -- In Transit --        -- Billing / Support --

QuoteRequested   ShipmentBooked     LabelPrinted     ParcelPicked    ParcelScannedAtHub    ParcelDelivered    InvoiceIssued   PaymentReceived
QuoteAccepted    PickupScheduled    HandoffReceived  ParcelInTransit                       DeliveryConfirmed                  SupportTicketOpened

                                                                         DeliveryExceptionRaised
                                                                         ReturnInitiated

Above commands and actors:

Customer ---> [BookShipment]  (blue)
Dispatcher ---> [ScheduleCarrierPickup]
Carrier (pink external) ---> emits scans

Below, policies:

Whenever ShipmentBooked,
  assign a carrier based on service class and contract.     (lilac)

Whenever ParcelDelivered,
  trigger invoice generation within 24h.                    (lilac)

Whenever DeliveryExceptionRaised AND customer is premium,
  auto-create a support ticket.                             (lilac)

And hot-spots:

RED: "What counts as 'delivered' -- the carrier scan, or the customer confirmation?"
RED: "Pricing and Billing disagree about when surcharges apply."
RED: "Returns timeline is unclear -- nobody here knows the end-to-end path."

Distilling bounded-context candidates

After the events are ordered and clustered, natural "swimlanes" emerge. The facilitator draws vertical lines where language, actors, and data change. For Parcel Shipping, the session proposes:

• Sales / Pricing (QuoteRequested -> QuoteAccepted)
• Shipping (ShipmentBooked -> LabelPrinted -> HandoffReceived)
• Tracking (ParcelPicked -> ParcelScannedAtHub -> ParcelDelivered -> ExceptionRaised)
• Billing (InvoiceIssued -> PaymentReceived)
• Support (SupportTicketOpened -> …)
• Carrier Gateway (external pink cluster)

These are candidates, not decisions. But they are candidates grounded in visible evidence, and everyone in the room participated in generating them.

Process-level zoom: "book a parcel"

The next week, a smaller group holds a process-level EventStorming on "book a parcel" (5 hours). Output:

Customer --> [BookShipment]
  --> ShipmentBooked
    --> Policy: assign carrier based on contract
      --> [AssignCarrier]
        --> CarrierAssigned
          --> Policy: request pickup slot from Carrier Gateway
            --> [SchedulePickup] (pink: Carrier Gateway)
              --> PickupScheduled
                --> Policy: print label within 30 min
                  --> [GenerateLabel]
                    --> LabelPrinted

Red hot-spots surfaced: "What happens if the chosen carrier refuses the slot?" and "Is pickup-scheduling failure a domain event or a retry?" Both become backlog items.

Software-design zoom: Shipping context

For the Shipping context, a design-level session places yellow aggregates on the board, clustering events that are triggered by commands on the same aggregate:

Aggregate: Shipment
  Commands: BookShipment, AssignCarrier, GenerateLabel, CancelShipment
  Events:   ShipmentBooked, CarrierAssigned, LabelPrinted, ShipmentCancelled
  Invariants:
    - Cannot GenerateLabel before CarrierAssigned
    - Cannot CancelShipment once LabelPrinted

This is the direct bridge from strategic discovery (events) to tactical design (aggregate in concept 10).

Common Confusion / Misconception

"EventStorming is a diagramming format." It is a workshop format. The output is a byproduct of the conversation. A pretty board with no argument is a failed session.

"Events must be technical events." They must be past-tense business facts. ShipmentBooked and InvoiceIssued are good; RowInsertedIntoShipmentsTable is not.

"You need Miro for EventStorming." Brandolini recommends 8 meters of paper and physical sticky notes precisely because it forces proximity and physical movement. Virtual tooling is fine when remote, but it is not the default.

"One session is enough." Big-picture gives you the elephant; process gives you the seams; design gives you aggregates. You usually run all three as separate sessions with different participants.

"The facilitator should be the senior architect." The facilitator should be a neutral facilitator. Architects talk too much. The domain experts need to feel heard.

"Commands come before events in time, so we should write commands first." No -- events first, always. Events are facts the business recognizes; commands are inferred from events. Writing commands first imports too many implementation assumptions.

How To Use It

To run your first EventStorming:

1. Pick the scope (big-picture vs process vs design-level).
2. Invite the right people: domain experts first, engineers second, management third.
3. Buy the materials: orange stickies, blue, lilac, pink, yellow small + large, a red pack, a long paper roll, lots of sharpies.
4. State the prompt: "Let's map everything that happens in the life of a parcel at our company."
5. 10 minutes of silent chaos writing (everyone writes past-tense events without ordering).
6. Enforce the timeline. Put events in left-to-right order. Duplicates collide -- pick one.
7. Add actors, commands, external systems, policies, read models in that order.
8. Mark hot-spots in red as they surface.
9. Cluster into candidate bounded contexts -- use vertical lines.
10. Photograph everything. Write a one-page summary the same day (before memory fades). Capture hot-spots as a backlog.

Check Yourself

1. What is the difference between a command and a domain event?
2. A participant says "well, sometimes we skip label printing." How would that show up on the board?
3. Why does the facilitator discourage nouns like Shipment, Invoice, Customer during the first 30 minutes?

Mini Drill or Application

Run a 90-minute big-picture EventStorming for one of:

• Conference Ticketing (sales -> check-in)
• Parcel returns (from "customer initiates return" to "refund issued")
• Your own team's primary flow

You can run it solo by role-playing three stakeholders. Produce:

1. A photograph or Mermaid representation of the final timeline.
2. At least 5 policies.
3. At least 3 red hot-spots.
4. 3-5 candidate bounded contexts with 1-sentence justifications.

Read This Only If Stuck

• Learning DDD: What is EventStorming? To Step 6 Policies
• Learning DDD: Step 7 Read Models to Exercises
• Alberto Brandolini - EventStorming.com
• The EventStorming Handbook - Paul Rayner
• Introducing EventStorming - Alberto Brandolini (free sample)