EventStoming 

To ensure a same understanding of complex business processes and effectively implement Domain-Driven Design that aligns with business logic and software requirements, stakeholders, involved in the different business domain, should participate in collaborative meeting or workshop and brainstorm on the project’s features.

The main purpose of such meetings is to build effective communication among stakeholders, including the product owner, software architect, QA team, domain expert, and developers. By gathering  parties and groups with different business understanding together, we aim to find a practical technical solution and ensure that each participant understands the perspectives, approaches, and terminology of the others.

Such meetings or workshops that the team members from different parts of company partaking on designing a software proactively is named EventStorming, which is created by Alberto Berandolini for the first time to facilitateTactical Domain-Driven Design.

It is a flexible workshop format for collaborative exploration of complex business domains. The adaptive nature of EventStorming allows sophisticated cross-discipline conversation between stakeholders with different backgrounds, delivering a new type of collaboration beyond silo and specialization boundaries. --  Alberto Brandolini, EventStorming

Regarding my experience, EventStorming is an effective tool for tackling a range of challenges within an organization. It proves particularly valuable in addressing the following areas:

Building a ubiquitous language: This language (ubiquitous language) bridges the gap between technical and non-technical teams, ensuring that everyone in the company, regardless of their role, has a clear and common understanding of the product.

Modeling a New Business Process: It is ideal for designing a new business process from the scratch.

Enhancing an Existing Business Model: To align with new requirements, certain business models may need to be migrated or transferred. EventStorming can be a valuable tool in refining these models. It not only enhances the current structure but also helps identify and prioritize the key areas for migration.

Concerns & Definitions 

Before beginning, it’s crucial to thoughtfully select the participants and colleagues who will join the workshop. While it may seem like a great opportunity for everyone on the team to collaborate on a project and develop software together, managing and handling a large group and ensuring active participation from all participants can be challenging.

Just keep in mind that the goal of the workshop is to learn as much as possible in the shortest time possible. We invite key people to the workshop, and we don’t want to waste their valuable time. -- Alberto Brandolini, EventStorming

  1. The size of the workshop and the number of participants is the first and often the most challenging consideration. It's highly recommended to limit the team size to no more than 10-12 people. Keep in mind that EventStorming can be a time-intensive process, and time is money. Additionally, as I highlighted when introducing Domain-Driven Design, not every project requires DDD, and by extension, not every project will benefit from this workshop. 
  2. Therefore as the second consideration, before diving into EventStorming workshop, it’s crucial to have a compelling reason, such as those I’ve outlined earlier, for investing the time and effort into this exercise.

Workshop Prerequisites

An EventStorming workshop, as described, is a collaborative session where participants and stakeholders engage actively. To ensure the workshop is both productive and effective, three key prerequisites must be met:

  1. Playground: To model software effectively, we need a space that encompasses its domains, components, behaviors, and events. For in-person workshops, it is recommended using a wall covered with white paper as a collaborative workspace. This allows participants to fill the space with sticky notes that outline key business domains at a high-level. In a virtual setting, web-based tools like Miro can serve as effective alternatives, offering similar interactive experiences online.
  2. Sticky Notes: They are the primary tools in an EventStorming workshop. Different colors represent various aspects of the business domain, which will be explored in the following section. This tool is also available for  workshops on web-based platforms.
  3. Marker: For outlining connections and defining boundaries.

Business Domain Description

In addition to the playground and markers described  above, sticky notes, as mentioned, are the most impactful and effective tool in this workshop. These notes, available in various colors to represent different concepts, allow us to clearly and thoroughly explain our business domain. The concepts and their corresponding colors are listed below:

To run certain services in specific situations, commands should be sent or generated by the actor or other services. The used sticky note is blue.


Actors in Event Storming are the entities that trigger events within a system or a real person who executes a command to trigger or initiate a service. The used color is dark yellow.

Red sticky note represents a problem or a blocker. These play crucial roles in workshop because they help participants  identify and address obstacles early in the design or problem-solving process.

In Domain-Driven Design, aggregates are a fundamental concept that shapes the structure of the domain model and encapsulates business logic. An aggregate is a collection of related objects, including entities and value objects, that function as a cohesive unit.

In an event storming workshop, a Policy refers to a rule or condition that guides how a system should act in specific situations. It usually consists of a logical statement, like a rules engine that triggers commands, defines business rules, intermediary between events and commands, and represents decision-making processes. 

A Domain Event plays a crucial role in representing occurrences in domains or changes in the state of a system within a business domain. It is a useful definition for grasping and defining how a system behaves and how different domains interact over time. Furthermore, it helps to find out the domain boundaries and capture domain business knowledge. Keep in mind that Domain Events reflect events that have already occurred within the system, so they should always be expressed in the past tense.

In an Event Storming workshop, an External System represents a  component that interacts with the domain but is outside of its boundaries. In other words, It’s not directly controlled by the domain, and its behavior is not modeled in detail during the workshop. Instead, the focus is on how this external system interacts with the domain, typically through commands or events.

The Read Model in EventStorming workshop is essential for how a system queries and retrieves information, especially within business domains. The Read Model provides actors or users with metadata about processes, domain events, and other relevant information.


Workshop Steps

An EventStorming Workshop generally follows a series of key steps that help participants move from understanding the domain to identifying and addressing issues. While the specifics can vary depending on the facilitator or the workshop's objectives, the process typically involves six main steps.

Defining and Organizing Domain Events: As the first step, let us to start by identifying all potential events that could occur within the business domain. Write these events on orange sticky notes and arrange them according to the team's understanding of the requirements and the business’s priorities. The we have to carefully review and refine the list of events. In other word, we have to to remove any events that are irrelevant or unnecessary. 

During this process, it's important to identify the key events that represent significant transformations and changes within the domain. These pivotal events will form the foundation for your domain model and they are key points to define boundaries between domains.

Defining Commands & Policies: In this step, our goal is to identify the reasons for generating domain events and determine where these events should go.  We start by defining commands, which are initiated by actors to fulfill specific needs or intentions.  These commands lead to the creation of domain events.

On the other hand, domain events serve as triggers for policies. These policies respond to the events by executing one or more commands, thereby driving the system's behavior forward in a structured manner. This process helps create a clear, actionable flow within the event-storming model.

Defining Aggregates: In each bounded context, there are one or more aggregates that play a crucial role. They are responsible for processing incoming commands and generating the appropriate domain events. In essence, they establish the logical connection between commands (inputs) and the resulting events (outputs).

Understanding and Explaining Read Models and External Systems: At this stage, it's important to identify whether third-party services or software can streamline our development process. By leveraging these external systems, we can benefit from general solutions (also known as Generic Subdomains) that reduce our workload.  Additionally, we should clearly define the incoming data — such as the sequence of orders in an e-commerce platform — using green sticky notes to keep everything organized and visible.

Illustrating Business Domains (Bounded Contexts): This step involves grouping related aggregates and domain events into a cohesive unit known as a bounded context.  Within each bounded context, a consistent and shared language — referred to as ubiquitous language — is developed and defined. This ensures that all terms and concepts are understood uniformly within the context, promoting clarity and reducing ambiguity.

Address Doubts and Ambiguities: In the final step, each participant should place their questions and concerns on red sticky notes. These notes should be attached next to any task or idea that seems unclear or potentially risky to develop.

Burger-Best - A Case Study

To fully understand the EventStorming workflow and how to do it in an effective way, we investigate together a case study to illustrate the different domains in designing the online shop for a fictitious fast food company, Burger-Best.

Burger-Best currently operates a single location in downtown and aims to expand its business by offering online ordering with complimentary delivery throughout the city. 

What makes the steps in the figure above easier for the development team to understand and implement is the alignment of high-level business goals with the code-base, facilitated by EventStorming. 

In this process, we gather with all stakeholders to explore the problem space of Burger-Best and develop a shared understanding of the business domains, leading to a well-defined solution.

Defining and Organizing Domain Events: In Burger-Best, a system designed for selling hamburgers, each team member begins by brainstorming all possible events that could occur from the time an order is placed until it is delivered. Remember, put all possible events first, then remove any unnecessary sticky notes from the wall.


Domain events like "payment finalized" and "order delivered" can occur within a domain and may be used by the aggregate that generated them or by other aggregates. However, certain events, known as pivotal events, are particularly important in the event flow. These pivotal events are crucial for defining bounded contexts, as mentioned earlier.

Define Commands & Policies: To generate domain events, there must be a corresponding command or system-defined policy that triggers them. In other words, each event requires a specific reason to occur within the domain.  At this stage, it is necessary to establish the connection between domain events and the specific policies or commands that produce them. Additionally, you should define the commands that are triggered by particular policies.


For instance, In a traditional kitchens, a chef starts cooking a hamburger by manually initiating the process by a command. In contrast, modern fast-food chains like McDonald's and KFC use automated systems, where the cooking begins automatically based on predefined guidelines or policies.
In this project, we are designing a traditional kitchen and delivery system. Consequently, most of the domain events are activated through commands involving key participants such as drivers, customers, and chefs.

Defining aggregates: Now is the time to analyze commands, policies, and domain events to understand their interactions and define the logic using aggregates. As noted earlier, there can be multiple aggregates within each bounded context, depending on the domain's complexity. Additionally, applying clean architecture principles can result in having more than one aggregate within a single bounded context.

When defining the number of aggregates in a domain, it's crucial to follow the SOLID principles. In my experience, having a single, overly comprehensive aggregate — akin to a "God Class" within a bounded context — can easily lead to what is known as a "Big Ball of Mud."

Understanding and Explaining Read Models and External Systems: In our event-stormed model, outsourcing online payments to a third-party service (an external system) proves to be both cost-effective and efficient.
Additionally, when pivotal events need to be passed to the next bounded context, a queue can serve as a read model—such as for managing orders in the kitchen and delivery processes.

We should consider adding more queues to the model in the following scenarios:
  1. When there's a backlog of orders that need processing.
  2. When the time required to analyze commands or policies in different aggregates varies, causing one aggregate to wait for another.

 Illustrating Business Domains (Bounded Contexts):  It is time to define Boundaries!  In the Burger-Best event-stormed model, we can identify four aggregates, each of which could serve as the core of a bounded context, as shown here.


We can merge the "Online Payment" and "Online Shop" domains into a single bounded context. This approach offers a key advantage: it streamlines the organization of development teams, making it easier to align engineers and developers with the project’s goals. Keep in mind that various design options are available for the project, and the final solution will depend on the decisions made by stakeholders and participants during workshops.

Address Doubts and Ambiguities: There's no such thing as a dumb question—only a dumb answer. In real-world event-storming workshops, where models are crafted to meet a variety of functional and non-functional requirements, it's common to encounter numerous bounded contexts and domains. These often lead to ambiguities and uncertainties among participants during the workshop. It's very important to ask questions at this step, as each one can save significant time and money in the long run.

Wrapping Up

EventStorming is a vital technique in Tactical Domain-Driven Design that emphasizes collaboration between team members and stakeholders. The primary goal is to create a shared understanding of the business domain and develop solutions that align with business needs.

EventStorming not only facilitates effective communication and understanding among team members but also helps identify potential problems and opportunities early in the development process. By fostering a shared language and collaborative environment, EventStorming ensures that all stakeholders are aligned, reducing miscommunication and improving overall project efficiency. This alignment ultimately leads to more robust solutions and successful product outcomes.

No matter the complexity, incorporating EventStorming into a company's culture and workflow is essential for successfully bringing products to market on time. 

Share This Article