Event Storming

1. Introduction

Event storming is a collaborative workshop method for domain exploration that helps teams model complex systems. Unlike traditional methods such as Entity-Relationship Diagrams or Unified Modeling Language, which often focus on static structures and require extensive planning, event storming is fast, interactive, and focuses on domain events as the core building blocks.

In this tutorial, we’ll explore the basics of event storming, discuss its benefits and shortcomings, and go through an example.

2. Overview of Event Storming

Event storming is popular in Domain-Driven Design because it encourages creativity, allows rapid discovery of key concepts, and promotes teamwork.

Created by Alberto Brandolini, event storming helps teams model complex business processes by mapping out events, interactions, and domain relationships.

It’s a workshop approach that brings together diverse perspectives to create a visual, event-driven model of a domain.

3. Types of Event Storming Workshops

There are three types of event-storming workshops.

In big-picture event storming, we focus on mapping the entire system, giving a high-level overview.

In contrast, process-level event storming focuses on specific workflows or processes within the system.

Finally, in design-level event storming, we handle detailed sessions to create an implementable domain model.

Let’s take a look at each of these types in more detail.

3.1. Big-Picture Event Storming

Big-picture event storming maps out the broad structure of our system by focusing on events that highlight key actions within the domain.

For instance, in a food delivery application, we can start by identifying the events occurring from when a user signs up to completing their first order. This approach helps us capture the essential flow and understand the system’s core interactions:

The goal is to create an overview of the domain by listing all major events.

The participants are owners, developers, domain experts, and stakeholders, each bringing a unique perspective to the process. Product owners and stakeholders provide strategic insights, while domain experts contribute in-depth knowledge of business processes. Developers then translate these ideas into actionable design elements.

The outcome of this event storming is a holistic understanding of the system and potential opportunities for improvement.

3.2. Process-Level Event Storming

Once we have the big picture, we can dive into specific workflows. In process-level event storming, we take one process and examine each step in more detail.

For example, in our food delivery app example, we can examine the details of Order Placement:

The goal is to gain a more in-depth understanding of the system’s workflows.

Participants typically include developers and subject matter experts who specialize in the specific workflow being analyzed.

The expected outcome is the discovery of process bottlenecks, exceptions, and dependencies.

3.3. Design-Level Event Storming

In design-level storming, we move from abstract processes to designing a detailed, technical model.

For instance, in our order placement example, we’ll add specifics like aggregates, commands, and policies that will ultimately inform our application’s structure:

The goal of design-level event storming is to develop an implementable model.

Developers and architects participate in this process. The desired outcome is a domain model aligned with business needs and ready for development.

4. Key Components

Event storming relies on color-coded sticky notes, where each color represents a different type of information in our domain:

Using these categories helps us visualize the flow of information and interactions within our system.

For example, the events capture essential actions within the domain, such as Order Created or Payment Processed in our food delivery app. Commands trigger these events, like Place Order or Confirm Delivery. We use aggregates to represent core domain objects, such as User Account and Order, that manage data and handle system events.

Policies introduce conditional rules that shape how commands and events interact. For instance, that’s Free Delivery for High-Value Orders in our app. Finally, external systems represent connections with outside services, showing where our domain interacts with third-party providers. Examples are Payment Gateway and GPS Service in our food delivery application.

5. Setting Up an Event Storming Workshop

Now that we know the types and key concepts, let’s learn how to set up an event-storming workshop.

5.1. Prepare the Space

To get started, we’ll need a large, open space where everyone can contribute. Storming works best when participants are active, so consider using a wall or large whiteboard to display sticky notes.

We’ll need sticky notes of different colors (orange, blue, yellow, green, pink), markers, adhesive tape, and large paper rolls or whiteboards. Once our materials are ready, we’ll arrange the sticky notes by color and leave enough room on the board for each workflow segment.

5.2. Define Workshop Goals

Clear goals keep the session focused.

In our food delivery app example, we aim to understand the customer journey from order placement to delivery. In a big-picture session, we identify events from user registration through to completed orders, while process-level workshops might focus on just one part, such as payment processing.

It’s essential to keep the session aligned with the intended scope. For example, going into specific details during a big-picture workshop can distract us from understanding the overall flow.

5.3. Gather the Right People

A diverse group improves outcomes as each participant brings a unique perspective:

• Domain experts bring in-depth knowledge of the business.
• Developers and architects translate domain concepts into technical requirements.
• Stakeholders provide insights into goals and priorities.

However, not all roles participate in every type of session.

For instance, in a big-picture session, stakeholders and domain experts are crucial in outlining the overall workflow. Similarly, developers and architects are more involved in process-level and design-level sessions, where technical details come into focus.

6. Conducting an Event Storming Workshop

Now that we set up the theory, let’s use the food delivery app as an example.

6.1. Step 1: Identify Core Events

Events are the foundation of Event Storming. We start by identifying key actions in the Order Workflow of our food delivery app, such as:

1. User Registers
2. User Searches for Restaurants
3. Order Created
4. Payment Processed
5. Delivery Dispatched
6. Order Delivered

We must encourage everyone to add events that seem essential to the workflow. This step helps us build a common understanding of how each part of the system interacts.

6.2. Step 2: Add Commands

Once we have the core events, we add commands that trigger these events. Commands are typically user actions or system prompts. In our example, we might have:

• Place Order: triggers Order Created
• Make Payment:  triggers Payment Processed
• Confirm Delivery: triggers Order Delivered

By mapping commands to events, we can see how users and systems interact in each phase.

6.3. Step 3: Define Policies and Business Rules

Policies represent business rules that dictate when commands should trigger events. So, policies capture the decision points in the workflow.

Here are a few examples:

• Payment must be verified before dispatch.
• Orders over a threshold value get free delivery.
• Dispatch only when delivery staff is available.

Adding policies lets us refine the model to reflect real-world conditions and business rules.

6.4. Step 4: Map Aggregates and External Systems

Next, we identify aggregates or groups of related entities. Aggregates are crucial for managing data and business logic.

For our food delivery app, we might define aggregates such as user account, order, and delivery. We also add external systems, such as a Payment Gateway for processing payments or a GPS Service for delivery tracking.

Mapping aggregates and external systems shows how different entities and external services interact in our app.

6.5. Step 5: Review and Refine

With our events, commands, policies, aggregates, and external systems mapped out, we now discuss and refine the model.

This step involves reviewing each event to confirm its relevance and accuracy. So, we should encourage participants to ask questions, challenge assumptions, and suggest improvements.

7. Benefits and Limitations of Event Storming

Event storming offers several benefits for domain modeling, making it a preferred choice in many projects. First, it enables quick understanding; unlike traditional methods, event storming delivers fast, actionable insights into complex domains. Additionally, the process encourages cross-functional collaboration, involving participants from various roles to include all perspectives.

This collaborative approach fosters domain knowledge sharing, allowing domain experts and developers to align on requirements and goals, which helps reduce the need for rework down the line. Finally, the structured output from an event storming session often translates seamlessly into actionable design elements, improving the overall software design and development process.

However, event storming has some limitations. Its success depends on group dynamics, and session effectiveness depends on participants’ domain knowledge and engagement. If discussions become too detailed in a big-picture session or if participants lack expertise in a design-focused session, we may lose focus.

Additionally, event storming may miss finer technical details that emerge later. Therefore, it’s most effective as a complementary rather than a standalone approach.

8. Conclusion

In this tutorial, we explored event storming as a hands-on, visual approach to domain-driven design. Through our food delivery app example, we saw how to use event storming to map out events, commands, policies, and aggregates in a practical, collaborative setting.

One of the most significant advantages of event storming is its ability to create a shared understanding among diverse team members, from developers to domain experts. This shared view not only accelerates insights into the domain but also ensures that everyone is aligned on goals and requirements, reducing miscommunication and rework. We can use event storming to model a new system or improve an existing one.