Event Storming Is a Language, Not a Workshop

Mike Dyer March 30, 2026 9 min read

The DDD community treats Event Storming as a workshop activity. You book a room. You buy sticky notes — orange for domain events, blue for commands, yellow for aggregates, purple for policies, pink for hotspots. You invite the domain experts, the developers, the product managers. You fill a wall. You photograph it. You translate it into Jira tickets and architecture diagrams. Then the sticky notes come down and the wall goes back to being a wall.

That's how Event Storming is taught, practiced, and discussed. As a facilitated session with a physical output that exists for as long as the adhesive holds.

I think this framing buries the most important thing Brandolini created. And I think the evidence shows that what he created is bigger than the workshop format can contain.

Start with the sticky note colors. They aren't a workshop convenience. They're a type system.

Orange means "something happened" — a domain event. Blue means "someone or something wants to cause a change" — a command. Yellow means "this thing owns state and enforces rules" — an aggregate. Purple means "when this happens, do that" — a policy. Pink means "we don't understand this yet" — a hotspot. Lilac means "this is derived data" — a read model.

Each color is a semantic classification. Each classification carries behavioral expectations. An orange sticky doesn't just label a fact — it declares that something irreversible occurred in the domain, that downstream consequences may follow, and that the system's state changed in a way that matters to the business. A purple sticky doesn't just describe a reaction — it declares a stateless causal link between an event and a command, a temporal dependency that governs how the system behaves over time.

These aren't categories you impose on a domain. They're structural roles that domain concepts naturally fill. Every domain has things that happen (events), things that cause change (commands), things that own state (aggregates), and things that react to change (policies). Brandolini didn't invent these roles. He gave them colors.

The question is whether the colors — the vocabulary — are bound to the workshop format, or whether they describe something about reactive systems that exists independently of sticky notes on a wall.

Here's the argument that they do.

Take any reactive domain and model how it behaves over time. Not what it is — what it does. Follow a single business process from trigger to completion.

A customer places an order. That's a domain event — something happened. The system needs to reserve inventory. That's a policy — when an order is placed, initiate reservation. The policy produces a command — ReserveInventory. The command executes against the Inventory aggregate, which checks stock levels, enforces the invariant that reserved quantity cannot exceed available quantity, and emits a new event — StockReserved. That event triggers another policy — when stock is reserved, initiate payment capture. Payment capture produces a command against the Payment aggregate. The Payment aggregate processes it and emits PaymentCaptured. Which triggers the fulfillment policy. Which produces the CreateShipment command. Which executes against the Shipment aggregate. Which emits ShipmentCreated.

Event → Policy → Command → Aggregate → Event → Policy → Command → Aggregate → Event.

Orange → Purple → Blue → Yellow → Orange → Purple → Blue → Yellow → Orange.

I didn't import Event Storming to produce that decomposition. I described what happens in the domain over time, and the vocabulary appeared. The events are events because irreversible things happened. The policies are policies because stateless reactions connect those events to actions. The commands are commands because something needs to change state. The aggregates are aggregates because something owns the state being changed and enforces the rules about how it changes.

The reactive flow isn't a framework. It's how temporal causality decomposes in bounded systems. Brandolini's colors are a notation for a structure that already exists in every reactive domain.

Now go further. Look at what happens at the boundaries.

The OrderPlaced event was emitted by the Order aggregate in the Order bounded context. But the InventoryReservation policy lives in the Inventory context. That event just crossed a context boundary. The policy that consumes it doesn't know anything about the Order aggregate's internals — it only knows that something happened and it needs to react.

This is where Evans' Anti-Corruption Layer meets Brandolini's reactive flow. The context boundary is the place where the event's semantics must be translated — where OrderPlaced in the Order context becomes a signal that the Inventory context interprets through its own ubiquitous language. The policy is the translation mechanism. It sits at the boundary, consumes a foreign event, and produces a command in the local context's vocabulary.

Brandolini's purple sticky — the policy — is doing the same work as Evans' ACL. It's the boundary translation layer for reactive flows. This isn't a metaphor. It's a structural equivalence. The policy sticky note is the temporal version of the spatial ACL. Evans described how bounded contexts protect their internal models from external semantics. Brandolini described how bounded contexts react to external events through local translations. Same architectural function, different dimension — space versus time.

Nobody in the DDD literature has formalized this equivalence. Evans writes about spatial boundaries. Brandolini writes about temporal flows. The two vocabularies coexist in the community without anyone pointing out that they're describing the same boundary mediation from different angles.

The shift that made this visible to me came from an unexpected place.

Narrative Driven Development — Sam's work — introduced a framing that reoriented how I think about domain events entirely. NDD treats domain events not as data payloads or state transitions, but as moments in time. A domain event isn't just a record that something changed. It's a moment with temporal significance — it happened at a point in time, in a sequence, with causal relationships to what came before and what comes after.

This sounds like a nuance. It isn't. It's a reorientation of the entire modeling perspective.

When you think of events as state changes, you model them as facts about aggregates. "The order's status changed to Placed." That's spatial — it describes the aggregate's state at a point. When you think of events as moments in time, you model them as points in a causal sequence. "An order was placed, which means inventory must be checked, which means payment must be captured, which means fulfillment must begin." That's temporal — it describes what unfolds across the system as a consequence.

The spatial framing keeps you inside the aggregate. The temporal framing pulls you across boundaries, through policies, into the reactive flow that connects the entire domain. And the moment you model with temporal scope — events crossing boundaries over time — Event Storming's swim lane vocabulary isn't something you choose to use. It's the structure your model produces.

NDD planted the seed. Months of building grew it into something I couldn't ignore: the reactive flow decomposition isn't Brandolini's invention. It's a property of temporal domain modeling that Brandolini's workshop makes visible. The workshop is one discovery mechanism. Temporal modeling is another. They converge on the same structure because the structure is in the domain, not in the method.

Here's where this gets practically important and stops being philosophical.

If Event Storming's vocabulary is a discovered structure rather than an invented method, then access to that structure doesn't require the workshop. This matters because the workshop has prerequisites that exclude a large part of the DDD community.

You need a room. You need domain experts who can dedicate half a day or more. You need a facilitator skilled enough to keep the session productive. You need developers and product people in the same physical or virtual space. You need the organizational authority to pull all of these people out of their day jobs simultaneously.

Solo practitioners don't have this. Small teams don't have this. Engineers at companies where domain experts are executives who won't sit in a four-hour workshop don't have this. The workshop format creates an accessibility barrier that locks out precisely the people who would benefit most from the vocabulary.

But the vocabulary works without the workshop. You can model a domain's temporal behavior alone — event by event, policy by policy, command by command — and arrive at the same reactive decomposition that a room full of sticky notes would produce. Not because you're doing Event Storming without the workshop. Because you're modeling temporal causality, and the structure is the same regardless of how you discover it.

The workshop is valuable. Brandolini's facilitation techniques surface domain knowledge from non-technical experts in ways that nothing else matches. The physical, collaborative, high-energy format produces insights that solo modeling rarely does. If you can run a workshop, run one.

But stop telling people that Event Storming requires the workshop. It doesn't. The workshop requires Event Storming's vocabulary. The vocabulary doesn't require the workshop. The distinction matters because thousands of practitioners are locked out of the method by logistics while the language sits there, available, waiting to be used.

There's a deeper point here about what Brandolini actually contributed to DDD.

Evans gave us the spatial vocabulary — bounded contexts, aggregates, entities, value objects. The nouns of domain modeling. The things the system is.

Brandolini gave us the temporal vocabulary — events, commands, policies, read models. The verbs of domain modeling. The things the system does.

These aren't competing frameworks. They're complementary dimensions of the same domain. Evans models the space. Brandolini models the time. Together, they give you a complete vocabulary for describing what a system is, what it does, how it reacts, and how it changes.

But the community treats Evans as the foundation and Brandolini as a workshop technique. That's wrong. Brandolini's vocabulary is as foundational as Evans'. It's just been trapped inside a workshop format that makes it look like a facilitation tool instead of what it actually is — the temporal half of domain-driven design.

Event Storming isn't a workshop. It's a language. The workshop is one way to speak it.

It's not the only way.

This is an independent post — not part of the Signal-Driven Development series. More at listenrightmeow.hashnode.dev