Domain storytelling vs EventStorming
In our last post, we looked at domain storytelling. It’s a workshop format that brings together domain experts and the development team. Another workshop format that does that, is EventStorming [1].
EventStorming
EventStorming comes in three flavors:
- Big Picture: discovers the intricacies of an entire business.
- Process Modeling: targets a single, end-to-end process.
- Software Design: continues where process modeling leaves off to reach a full design of the software that supports the process under consideration.
The outcome of an EventStorming session is a wall of stickies. In the case of a Software Design session, those stickies form a design of a software system, which is an incredibly powerful artifact to feed into the remainder of the Software Development Lifecycle (SDLC). Let’s call this artifact an event storm.
Comparison with domain storytelling
Both workshop formats use a grammar of sorts. Domain storytelling uses constrained English sentences. EventStorming constrains which stickies can come before or after others. In both cases, this grammar helps someone new to a domain to ask intelligent questions. The EventStorming grammar is more detailed and closer to code.
The three flavors of EventStorming form a natural progression from coarse to fine-grained. You can also write domain stories at a coarser or finer-grained level, but there is no formal mechanism to go from one to the other.
Stories come much more natural to people than events, however. To be fair, EventStorming uses storytelling as well, but it lets the story evolve out of the events instead of taking it as the starting point. This works great if you don’t know what the story is, which is often the case in the Big Picture format, where experts from multiple subdomains come together. But if you’re looking at a single process, domain experts often already know the full story they want to tell.
Conclusion
Both workshop formats have a lot to offer. We want to use domain stories for communicating with domain experts, and we also want to have an event storm to kickstart the design. You could run both types of workshops [2], but there would be a great deal of overlap, so that’s not very efficient. Fortunately, there is a better way. Stay tuned.
References
[1] Brandolini, A. Introducing EventStorming, 2013.
[2] Junker, A. Mastering Domain-Driven Design, 2025.