Event Storming

Event storming is a workshop for surfacing domain events with the whole team in one room (or one virtual board), building a timeline of what happens in the domain before anyone argues about code.

The problem it exists to prevent is Brandolini’s own: it is developers’ misunderstanding, not domain experts’ knowledge, that gets released to production. The workshop drags that gap into the open early, while it is still cheap to fix, by making everyone model together instead of passing requirements down a chain.

The mechanics are deliberately low-tech. No computer, no UML: a long roll of paper on the wall and a lot of sticky notes. Orange stickies are domain events, phrased as past-tense facts and pinned in time order. Red stickies mark hotspots, the questions and disagreements nobody can resolve yet. From that timeline the group works outward to pivotal events, the commands that trigger events, the aggregates that own them, and finally the bounded contexts and subdomains that fall out of where the language changes. Brandolini’s advice is to embrace incompleteness rather than chase a perfect diagram.

The artifact is meant to be thrown away. In Verraes’s early facilitation account the closing move is to photograph the wall, then tell the team to discard the model and rebuild it the next day. What you keep is the shared understanding built in participants’ heads, not the picture. This is why a wall that gets photographed and quietly abandoned is not the failure it looks like.

It is a post-2003 format, not one of Evans’s patterns. Brandolini introduced it in 2013, calling the resulting model perfectly aligned with a Domain-Driven Design implementation style and particularly fitting event sourcing; Verraes, writing earlier the same year, framed it as deeply rooted in DDD and CQRS/event sourcing. That single original format later branched into three flavors: Big Picture, Process Modelling, and Software/Design-Level EventStorming, with Big Picture as the flagship, entry-level workshop rather than a successor that replaced the original. The 2013 recipe already reached down to aggregates and commands, so its design-level content lives on in Software/Design-Level EventStorming at least as much as in Big Picture. The DDD canon then adopted it from within: Vernon gives it a chapter in DDD Distilled (2016) as an “acceleration tool” for doing DDD, and Khononov teaches it in Learning DDD (2021) as the way to discover domain knowledge. It answers a real gap in the Blue Book, which described the modeling outcome far better than the collaborative format for getting there.

Signal: the team leaves with a shared timeline of named domain events it built together, not a diagram one person drew, and could throw the wall away without losing what it learned. Part of Domain-Driven Design.

Sources

• Alberto Brandolini, Introducing EventStorming: the workshop format from the person who invented it, including the developers’-misunderstanding problem it exists to prevent and the advice to embrace incompleteness. The book calls the resulting model “perfectly aligned with a Domain-Driven Design implementation style (particularly fitting an Event Sourcing approach)”.
• Mathias Verraes, Facilitating Event Storming (2013): the early facilitation account whose closing move is to photograph the wall, then throw the model away and rebuild it the next day; also the source of the stronger “deeply rooted in Domain-Driven Design, and CQRS/ES” description.
• Vaughn Vernon, Domain-Driven Design Distilled (2016): gives Event Storming a chapter as an acceleration tool for doing DDD.
• Vlad Khononov, Learning Domain-Driven Design (2021): teaches event storming as the way to discover domain knowledge.