Event storming is a rapid, lightweight, and underappreciated group modeling technique that is intense, fun, and useful for accelerating development teams. The brainchild of Alberto Brandolini, it's a synthesis of facilitated group learning practices from Gamestorming and the principles of domain-driven design (DDD). The technique isn't limited to software development. You can apply it to practically any technical or business domain, especially those that are large, complex, or both.
Event storming catalyzes and accelerates group learning, often achieving in a few hours or days what more traditional modeling techniques never do—a common understanding of the domain in which the software must operate.
To understand event storming you first need to understand two key terms. A domain event is anything that happens that is of interest to a domain expert. The domain expert is not interested in databases, web sockets, or design patterns, but in the business domain of the things that have to happen. Domain events capture those facts in a way that doesn't specify a particular implementation.
How event storming works
You run an event storming session as a facilitated workshop. Everyone participates, and the facilitator keeps the group focused and engaged, guiding progress toward a complete model of the domain. The group starts with domain events, walking through the model forwards and backwards to ensure that everything is covered. Then the group adds the commands, or triggers, that cause the events, and considers all sources of commands, including users, external systems, and even time.
The group identifies aggregates that accept commands and accomplish events, and begins to group aggregates together into bounded contexts. Along the way, key test scenarios, users, and goals are identified and incorporated into the model. Finally, the relationships between bounded contexts are added to create a context map. The resulting model is then challenged with code in order to validate the group learning and verify the model.
While event storming is growing in the DDD community, it's almost unknown outside of that sub-specialty. That's a shame, because only the facilitator has to be a DDD practitioner to guide the group toward a complete model. Everyone, including nontechnical product owners, can participate in understanding and modeling the domain. The better the entire team understands the domain, the more likely the software implementation will reflect the domain, which is the primary purpose of DDD.
Going faster
If you could do the project you just finished all over again, with the same team, knowing what you all know now, would you be able to complete it faster?
Yes, because you would already have learned what you needed to know to succeed. The slow speed of group learning is the primary constraint in the software development process. As Brandolini put it, "Software development is a learning process; working code is a side effect."
Domain events help to build out the domain model; they function as its bones. This isn't a design, it's a model—one perspective on the domain. You use domain events to drive modeling because they're easy for both technical people and domain experts to understand. Domain events say little about the design and nothing about the implementation, which is exactly what you want from a good domain model.
A different modeling approach
More traditional DDD modeling efforts are usually done by small groups or individual developers, sometimes after a few conversations with the product owner about the data, objects, or behavior. Unfortunately, this starts modeling at a level that's too close to the implementation domain, rather than confined to the business domain. If you start with data modeling, your thinking and conversations will quickly digress into schemas, transactions, and other things that have nothing to do with the business domain. If you start from behavioral modeling, you'll get distracted as you break down behaviors into tasks and link them into processes.
Those are implementation concepts, not business-domain concepts. While there are myriad choices for representing data and implementing behaviors, there are no alternatives for domain events. Because domain events represent facts about the domain, these only change significantly when the underlying business changes. Domain events are thus a more stable and resilient scaffolding for your model.
But there's an even more compelling reason for this approach: limiting the initial discussions to domain events forces everyone, especially developers, to focus on the ubiquitous language of the domain. They must learn it, define it, refine it, and use it exclusively in conversations about the model.
While a model centered around domain events may lead naturally to an event-driven system design, such as event sourcing or command query responsibility segregation, that's a choice, not an obligation. The software that implements the model doesn't have to be event-driven, or even object-oriented (though these are often excellent choices).
Accelerating group learning
Think about the last project you completed. What did the developers have to do to understand the domain model and build the system? Chances are, in the process of playing their stories, the developers shuttled between domain experts, solution architects, test users, and other team members. While it's possible that this process will lead to a common understanding of the entire domain by all team members, it's unlikely. The domain knowledge transferred is too diluted, too disconnected, too isolated, and too fragmented to yield a complete model in any single developer's mind, much less a common model understood by the entire team.
Instead, these conversations can occur during an event storming session. Usually these conversations happen sequentially, but with event storming they all happen at once. In this way you can sort out any conflicts or discontinuities in any part of the domain while everyone involved is present and engaged.
The biggest impediment to DDD is the tendency for developers to focus on the things they understand extremely well—software-development concepts—instead of the business domain. One symptom of this can be seen when nontechnical people, such as product owners or user advocates, come out of meetings with developers and begin describing the system in programming terms rather than in business terms. If the developers don't understand the domain, they can't model it correctly.
When and where to use event storming
The most obvious time to use event storming is at a project's inception, so the team can start with a common understanding of the domain model. Another high-payoff time to use event storming is as part of a project's close, to capture and share what the team learned in the process of building the software. That's important because no single developer is likely to know the entire domain due to incidental discovery, modification, and limited exposure to other areas. It's also advantageous to use event storming on a smaller scale, such as when you're thinking about changing something, starting a new story, or working out different scenarios or alternatives.
Giving it a try
Event storming is intended to create and share a common understanding of the domain model; it's not a replacement for a design document, flow chart, UML diagram, deployment plan, architecture diagram, or anything else related to implementation. Think of it as a low-fidelity, temporary information radiator for sharing and confirming the domain model with others.
Give event storming a try, and you'll reap multiple benefits. Using collaborative group learning, you'll achieve rapid domain-driven modeling without everyone having to be a DDD expert, and your team and terminology will align with that of the business domain experts. The process is informal and inexpensive—all you need are paper, sticky notes, and pens, and you'll be well on your way to accelerating team productivity.
Further reading
For more on event storming and how to get started, follow these links:
Keep learning
Take a deep dive into the state of quality with TechBeacon's Guide. Plus: Download the free World Quality Report 2022-23.
Put performance engineering into practice with these top 10 performance engineering techniques that work.
Find to tools you need with TechBeacon's Buyer's Guide for Selecting Software Test Automation Tools.
Discover best practices for reducing software defects with TechBeacon's Guide.
- Take your testing career to the next level. TechBeacon's Careers Topic Center provides expert advice to prepare you for your next move.
