Event Storming for Domain Modeling

In software development, misalignment between business needs and technical implementation is a common source of failure. Event storming offers a powerful, visual workshop technique to bridge this gap by collaboratively discovering the core business processes that your software must model. This approach is foundational to domain-driven design (DDD), ensuring that your architectural decisions are rooted in a shared understanding of the problem domain.

What is Event Storming?

Event storming is a facilitated, collaborative workshop technique designed to rapidly explore and model a complex business domain. Unlike traditional requirements gathering, it brings together domain experts, developers, product owners, and other stakeholders in a room with a long roll of paper or a digital whiteboard. The primary goal is to create a visual, temporal map of business processes by identifying significant occurrences. This process forces explicit conversations about how the business operates, surfacing assumptions and knowledge gaps that would otherwise remain hidden until late in development. By making the domain tangible, it serves as a direct bridge between business intent and software design.

Core Building Blocks: Events, Commands, and Aggregates

The workshop constructs a model using three primary conceptual building blocks. Understanding these is key to participating effectively.

A domain event is something that has happened in the past within the business domain that is significant to the stakeholders. It is always expressed in past tense, such as OrderPlaced, PaymentProcessed, or InventoryLevelChanged. Events are the backbone of the model and are typically written on orange sticky notes. They represent facts that the system must remember or react to.

A command is an action or intent that triggers a domain event. It is usually the result of a user action, an external system call, or another event. Commands are written on blue sticky notes and placed before the events they cause, like PlaceOrder leading to OrderPlaced. Identifying commands helps clarify the triggers and decisions within a process.

An aggregate is a cluster of associated objects (entities and value objects) that are treated as a single unit for data changes. In event storming, aggregates represent the "things" that are responsible for handling commands and producing events. They are often modeled on yellow sticky notes, such as Order or InventoryItem. Defining aggregates is crucial for establishing transactional boundaries and consistency rules in the eventual technical design.

The Two-Phase Workshop Process

Event storming is typically conducted in two distinct phases, each with a specific focus. Moving from the broad to the specific is essential for success.

The big picture session is the exploratory phase. The goal is to understand the overall business flow without diving into technical details. Participants stick domain events on the timeline in the order they occur, creating a narrative of the business process. Questions like "What happens next?" or "Why does this happen?" are encouraged. During this session, you will identify triggers (commands) and start to see where different sub-processes or responsibilities might belong to different parts of the organization. This phase is about breadth and discovery, often revealing the scope of the entire system.

The design-level session is a deeper, more technical follow-up. It focuses on a specific process identified in the big picture session. Here, participants drill down to model aggregates, policies, and read models. The group debates which aggregate is responsible for which command, what business rules are enforced, and how events affect the state of the system. This phase directly feeds into software modeling, helping to define precise APIs, database schemas, and service boundaries. It translates the business narrative into a concrete design suitable for implementation.

Defining Bounded Contexts and Bridging Understanding

A critical output of event storming is the clarification of bounded contexts. As you map events and commands, you'll notice natural linguistic and conceptual boundaries. For example, the concept of a "Customer" might mean one thing in the Shipping context (a delivery address) and another in the Billing context (a credit score). Event storming makes these contextual differences visible, allowing teams to explicitly decide where one model ends and another begins. This prevents the common anti-pattern of a single, ambiguous, enterprise-wide data model.

Ultimately, the technique's greatest value is in creating a shared language, or ubiquitous language, between business and technical team members. The visual model becomes a living artifact that everyone can point to and discuss. When a developer later writes code for an OrderCancelled event, they are directly implementing a concept that the business expert named and agreed upon. This alignment drastically reduces misinterpretation and rework, ensuring the software architecture is both faithful to the business and pragmatically buildable.

Common Pitfalls

Even with a straightforward process, teams can encounter obstacles that diminish the value of event storming.

1. Skipping the Big Picture Session: Jumping directly into technical design is tempting but dangerous. Without first establishing the broad business narrative, you risk modeling a solution to a poorly understood or incomplete problem. Always start with the exploratory big picture phase to ensure all significant events and processes are on the table.
2. Involving the Wrong Stakeholders: The workshop fails without true domain experts—the people who deeply understand the business rules and processes. A workshop full of only developers will result in a technical guesswork model. Conversely, excluding developers can lead to a model that is impractical to implement. Ensure a balanced mix of business and technical perspectives.
3. Getting Bogged Down in Technical Debates Early: During the big picture session, avoid discussions about database choices, message queues, or REST vs. gRPC. The focus must remain on what the business does, not how it will be built. Facilitators should gently steer conversations back to business events and rules when they veer into premature technical implementation.
4. Failing to Capture Outcomes: The sticky note wall is ephemeral. If you don't systematically photograph, transcribe, and summarize the model and decisions made, the shared understanding will fade. Assign a scribe to document the final model, key debates, and identified bounded contexts immediately after the workshop concludes.

Summary

• Event storming is a collaborative visual workshop that maps business processes using domain events, commands, and aggregates to create a shared understanding between technical and business teams.
• The process has two key phases: the big picture session for broad business discovery and the design-level session for detailed technical modeling of specific processes.
• A primary goal is to explicitly define bounded contexts, clarifying where different domain models and languages apply within a larger system.
• It directly supports domain-driven design (DDD) by forging a ubiquitous language and ensuring software architecture is derived from an accurate business model.
• Success depends on involving the right mix of stakeholders, staying focused on business events during discovery, and diligently capturing the workshop's outputs for future reference.