Process Level Event Storming

A deeper Event Storming pass that adds commands, actors, read models, policies, and aggregates around each event so the board can be translated into code.

Process Level Event Storming is the deeper Event Storming pass where you add commands, actors, read models, policies, and aggregates around each event, until the board is detailed enough to translate into code.

After Big Picture Event Storming gives you the shape of the whole flow, you pick one slice and zoom in. Where Big Picture is mostly orange sticky notes, a process-level board is colorful: blue commands, yellow aggregates, green read models, pink external systems, and small yellow actors.

Reading the board becomes a sentence: an actor sends a command to an aggregate, which produces an event, which a policy reacts to, which triggers the next command.

The conversation also changes. Big Picture answers "what happens in this business?". Process Level answers "how exactly will we build this?". Implementation gaps that you could ignore at the high level now have to be filled. That's where the technique shines: the difficult questions appear on sticky notes, not in production three months later.

This level is usually run by the development team, sometimes with a domain expert in the room. Sessions are smaller and shorter than Big Picture. The output looks much closer to a design document than a discovery map.

You don't need a full Process Level session for every feature. Use it when you're kicking off a new module or aggregate, designing something that crosses module boundaries, or unpicking a legacy area before changing it. For a small tweak inside a well-understood part of the system, a quick whiteboard sketch is enough.

Notation

A Process Level board uses the full sticky-note palette. Reading it is like reading a sentence: an actor sends a command to an aggregate, which produces an event, which a policy reacts to, which triggers the next command.

• Orange: Domain events. Past tense. Carried over from Big Picture Event Storming.
• Red: Hotspots. Disagreements or open questions, parked for later.
• Blue: Commands. Imperative entry points ("Place Order", "Issue Receipt").
• Small yellow: Actors. The person or system triggering the command.
• Yellow: Aggregates. The entities that own the invariants around their commands and events.
• Green: Views / Read Models. Data shown to users, or consulted by a command to make a decision.
• Pink: External systems. Services outside the boundary you're modeling.
• White: Inputs or notes. Command payloads, plus open questions and assumptions you want to capture.
• Lilac: Policies. Automated reactions: "whenever X happens, do Y."

A note on naming

Some authors split this into two distinct levels: Process Modeling (modeling a whole business process end-to-end) and Design Level (drilling into one aggregate's commands, events, and invariants). In practice, the team decides how the use the tool. The same board often grows from one into the other as the conversation gets more concrete.