Skip to content
Nerdy beta

Event Storming

Discovery Domain Driven Design Facilitation

You cannot design a system you do not understand. Event Storming gets the whole room modeling the business process on a wall before anyone opens an editor.

Overview

Event Storming is a workshop-based discovery technique created by Alberto Brandolini. A cross-functional group stands in front of a long wall and models a business process by placing domain events on sticky notes in chronological order. Events are things that happened, written in past tense (“Order Placed,” “Payment Failed,” “Shipment Dispatched”). From that timeline, the group layers in commands (what triggered the event), aggregates (the entities that enforce the rules), read models (the data people need to make decisions), and external systems.

The power is in what the exercise surfaces. Business experts and engineers discover they use the same words to mean different things. Edge cases that would have been found in production get found on the wall. Boundaries between subdomains become visible, which directly informs where to draw service boundaries and how to organize teams. Event Storming produces the shared mental model that story mapping then slices into deliverable increments.

When to reach for it

Event Storming works best when the domain is complex, when the team is building or restructuring a distributed system, or when engineers and business stakeholders need to build a shared model from scratch. It is the go-to mapping technique for microservices architectures, event-driven systems, and any context where Conway’s Law means getting the domain model right also means getting the team boundaries right.

For simpler domains or when the focus is on user experience rather than domain complexity, User Story Mapping is usually the better fit. The two complement each other: Event Storming maps the domain, story mapping maps the user journey.

Resources