Event storming is a dynamic workshop technique that supports domain-driven design in software development. It can boost the team’s efficiency and reduce error risk, minimizing the back-and-forth in the development lifecycle.
If you haven’t been living under a rock, you’re probably familiar with the concept of brainstorming. It’s a widely used term for the process of generating a mess of ideas to sort them out and ultimately find the right one. Whether at work or in daily life, we all brainstorm from time to time. It’s pretty straightforward.
When organizing a cluttered living space, resolving a conflict with a neighbor, or choosing a career path, you need to explore different options and their potential consequences. Perfect solutions are not always available at hand, so it’s helpful to spark creativity and produce a slew of ideas that you can then subject to rational assessment.
The technique has probably been around for ages. It was popularized in the fifties and has been widely applied in the creative industry. Over time, it has expanded to other areas, including IT and business development.
Since gaining momentum, brainstorming has been refined and restructured many times, giving birth to a concept known as event storming – one of the most valuable techniques for problem-solving in digital business and beyond.
What is event storming? A workshop-based approach to domain-driven designing
Event storming is a lightweight, facilitated workshop-based method for discovering the underside of a technical or business process. In the context of software development, it’s a flexible, multi-stakeholder approach to exploring what’s going on in the domain (a targeted subject area) of a software program.
The method was developed by Alberto Brandolini in 2012 as a smoother alternative to the detail-intensive UML diagram technique. The core idea behind the format was to transcend silo boundaries and invite many domain experts to the table. Existing standards tended to leave valuable stakeholders out of the conversation and prioritize purely technical insights.
The projects developed in such a manner lacked agility and rapid problem-solving capacity. They were also prone to more errors later in the development life cycle. At worst, they produced effects unaligned with business objectives. The new approach provided a simple blueprint for early problem identification and maximizing positive outcomes.
Event storming is rooted in domain-driven design (DDD). It’s a software design paradigm that emphasizes adjusting software models to real-world business domains and seeks to create a shared language (the so-called ubiquitous language) between all stakeholders, including software developers, domain experts, business analysts, product owners, end users, etc.
In simple terms, DDD helps ensure the software speaks the same language as the business and solves its specific problems. Combining event storming and the DDD approach is one of the most efficient ways to build software that closely reflects the real-world workings of a particular business area – be it finance, healthcare, or e-commerce.
Event storming – how does it work?
The event storming method uses two key terms: a domain event and a domain expert. The former refers to any occurrence relevant to a domain expert – the latter being a business-focused stakeholder who brings real-world knowledge of the specific domain (e.g., finance, healthcare) to the workshop and helps ensure the model reflects actual business needs.
With its inherent flexibility event storming can take many forms. Overall, the process involves several key steps that help stakeholders achieve the desired objectives.
Gather the right people
The event storming session should involve all parties that can provide valuable input to exploring the domain in question. According to Brandolini, those are the people who know what questions to ask and the ones who can give proper answers. Such a group is typically a combination of business, IT, UX, and architecture team representatives.
Define the topic
In the first step, stakeholders should carefully define the topic they want to work on and make sure everyone is on the same page with the issue to avoid misunderstandings and focus tightly on the goal.
Create a modeling environment
Event storming is minimalist in terms of tool requirements. Everything revolves around color-coded sticky notes posted on a wide wall (if you have a remote team, use online whiteboards). Orange sticky notes cover domain events, and blue sticky notes relate to commands, which are event-causing operations. All in all, there are several categories with their usual color attributions, but you can define your own color scheme as long as it’s clear to everyone involved.
Start the “real” event storming
Now, in the third step, the proper event-storming process starts. Your team shifts to a higher gear and starts brainstorming all domain events involved in the business domain. Note all events in the past tense on sticky notes (one orange sticky note per event) and put them on a timeline, discarding all duplicates.
Connect domain events to commands
Once you have your events arranged, analyze them for causes and consequences. Define commands that triggered the events and identify the sources of commands, such as users, external systems (e.g., a payment gateway, email provider, shipping company, etc.), or internal processes. Commands typically represent how users interact with the system and are noted in the present tense, e.g., “submit your order,” “schedule an appointment,” etc.
Identify aggregates and delimit bounded contexts
Aggregates are clusters of related domain events and commands that represent the domain concepts and rules. They are closely tied to the concept of a bounded context – a distinct area of a larger domain. Each bounded context may contain one or more aggregates, encapsulating the domain logic and ensuring data integrity within that specific context.
Examples include inventory management or shipping in an e-commerce system or player management and in-game purchases in a gaming system. By identifying aggregates and their associated contexts during an even-storming workshop, your team can better understand the boundaries and relationships within the domain.
Iterate and refine
An event-storming workshop is not a linear set of one-time actions. To ensure the software implementation will fully reflect the domain, your team should explore different scenarios and continuously refine the domain model as new insights emerge. All ideas should be validated with subject matter experts and stakeholders.
Why would I need an event-storming workshop? Key benefits of event storming
Event storming offers numerous advantages for companies looking to boost efficiency and reduce superfluous expenses. Here are the essential ones.
It’s easy and fun
It’s easy to participate in and requires no technical expertise. The focus is on collaboration and problem-solving.
Common understanding
Event storming facilitates a shared understanding of the entire domain, processes, and requirements among all stakeholders, including technical and non-technical people (even outside the DDD community), reducing misunderstandings and rework in the implementation phase.
Creativity boost
Teams can explore alternative solutions together, fostering creativity and innovation and contributing to group learning.
Efficient problem solving
Visualizing problems makes them easier to grasp, while structured brainstorming provides unexpected solutions. Overall, you can use event storming to create a domain model much more efficiently than with isolated data modeling approaches.
It’s applicable for complex business domains
Event storming can help your team deal with both simple and complex challenges. It’s applicable for various purposes, also beyond software development.
The main limitations of event storming workshops to consider
Event storming is a powerful tool for leveraging domain knowledge in the software design process, but it has some essential limitations.
Limited scope
Event storming is most effective in the early design stages of the system. It might not catch all potential errors that emerge during later development phases like coding or implementation.
Too complex for large domains
An event-storming session can be too overwhelming in the case of very complex domains with numerous entities and interactions (breaking down the domain into smaller subdomains can help).
Reliance on facilitation
Managing numerous voices and sticky notes can become challenging. A skilled facilitator is crucial to keep the workshop focused and productive.
+1 (888)
413 3806