Event Storming: Domain Discovery for IT Architects

Event Storming is a lightweight, agile workshop for discovering knowledge about a business domain through close collaboration between business and IT. Created by Alberto Brandolini around 2013 as a practical answer to ineffective modeling meetings, it abandons classic data-and-entity modeling in favor of business events. For an IT architect it is a key analytical tool: it reveals bounded contexts, exposes hidden assumptions, and aligns everyone on a shared language long before the first line of code is written.

Where Did Event Storming Come From?

The Problems of Classic Requirements Engineering

The traditional approach to gathering business requirements in IT projects very often fails because of structural communication barriers between the world of business and technical teams. Voluminous analytical documentation becomes outdated almost the moment it is approved, and its interpretation differs drastically depending on whether it is read by a business expert or a developer. System architects, deprived of direct contact with real processes, are forced to design complex architectures on the basis of incomplete or misinterpreted assumptions — which inevitably gives rise to technical debt and systems that are hard to maintain.

The Origins of the Method and Its Link to Domain-Driven Design

The origins of Event Storming are tied directly to the need to break these communication barriers within the Domain-Driven Design (DDD) approach. The workshop's creator is the Italian software architect Alberto Brandolini, who developed the technique around 2013 as a practical response to the inefficiency of traditional modeling sessions. Initially the format operated under the name "event-based modeling", and its roots lie in inspiration drawn from training sessions run together with Vaughn Vernon during his IDDD Tour. The method was officially formalized with the publication of the book "Introducing EventStorming" in 2016, which cemented its position in software engineering.

The Essence of Event Storming

The main innovation of Event Storming is the rejection of the traditional paradigm of modeling data structures and entities in favor of modeling business events. Classic entity modeling forces participants to focus prematurely on static, database-centric aspects, which is unnatural for business experts and leads to shallow, often incorrect models. Instead, Brandolini proposed starting from Domain Events — historical facts that have already happened in the domain and carry real business value, expressed in the past tense.

Event Storming is an exceptionally lightweight, agile workshop for discovering domain knowledge, based on tight cooperation between business and IT. Its overriding goal is to build a so-called Ubiquitous Language — a coherent set of terms and definitions used by developers and managers alike — which drastically reduces the risk of interpretation errors at the implementation stage.

Why Should an IT Architect Master Event Storming?

The Architect's Role Beyond Drawing Components

The role of the software architect in modern IT organizations has evolved profoundly. Today's architect is not merely a designer of closed components and deployment diagrams; the core task is to deliver a technical structure that directly realizes and supports the enterprise's business strategy. Designing advanced systems without a prior, in-depth understanding of business processes is doomed to operational failure. Event Storming is a key analytical tool for the architect, enabling the natural, organic discovery of system boundaries and so-called Bounded Contexts — the areas of conceptual consistency of software defined in the Domain-Driven Design approach. By visualizing the flow of events, the architect can precisely define interactions between areas of the domain, plan integrations (Context Mapping), and set clear boundaries of responsibility for individual development teams.

Reducing Risk and Eliminating the Design Paradox

This is precisely where the workshop pays off: it drastically reduces the risk of making wrong architectural decisions. The visual character of Event Storming exposes hidden assumptions, conceptual conflicts, and non-linear process paths far earlier — before the first lines of code are written. This allows early detection of edge cases and of technical debt hidden inside manual processes, before they translate into costly fixes in finished software.

Levels of Abstraction in Event Storming

The technique scales flexibly and can be run at three different levels of abstraction, depending on the design goal:

• Big Picture Event Storming — the strategic level, used to map and explore an entire business, business line, or broad system in order to identify problems and domain boundaries.
• Process Level Event Storming — the tactical level, focused on precisely modeling a single, concrete flow end to end together with all its business rules and exceptions.
• Design Level Event Storming — the technical level, descending directly to software implementation patterns such as aggregates, commands, technical events, and class structures.

This article focuses on the first two levels: Big Picture and Process Level. It is these two stages that carry the greatest strategic value for an IT architect, enabling a smooth transition from the general structure of the enterprise to a precise process model without getting bogged down in implementation details early in the analysis.

Big Picture Event Storming

The Essence and Strategic Goal

The overriding goal of a Big Picture workshop is to gain a holistic understanding of the entire business domain and to map the processes taking place within it from a bird's-eye view. The session allows the team to quickly identify areas of greatest complexity, detect bottlenecks, and reveal information silos within the organization.

From an architectural and business perspective, Big Picture Event Storming is useful at key moments in a system's life: launching new (greenfield) initiatives, modernizing complex legacy systems, planning the decomposition of a monolith into microservices, merging independent operational systems, or onboarding new members of a development team.

The workshop involves a broad, interdisciplinary group: domain experts from various business departments, Product Owners, system architects, developers, business analysts, and key decision-making stakeholders. To run a physical session you need a long wall (usually 5 to 10 meters) covered with paper from a roll, on which participants place sticky notes in strictly defined colors. One of Alberto Brandolini's crucial rules is the absence of chairs — working while standing stimulates the group's engagement and dynamics.

Metadata: Big Picture Session Setup

Big Picture Artifacts

The visual grammar of the strategic level rests on a simple, intuitive set of colors that makes it easy for participants with different levels of technical knowledge to communicate without friction.

How a Big Picture Workshop Unfolds

A strategic workshop proceeds through strictly defined phases that transform the initial disorder into a systematized business model.

1. Chaotic exploration — all participants simultaneously write the domain events they know on orange notes and stick them to the wall without concern for order. The goal is to release the knowledge stored in participants' heads onto the modeling space, without judging correctness.
2. Ordering the timeline — participants, preferably in silence, arrange the events chronologically from left to right. This silent sorting prevents the most expressive people from dominating the discussion and forces everyone into physical engagement with the model.
3. Identifying Pivotal Events — the key events marking irreversible state changes (e.g. an invoice being sent) or a handover of responsibility between departments. They are marked with vertical separators on the wall, dividing the model into smaller, coherent sections.
4. Adding actors and external systems — the user roles and external systems involved in generating events are matched to the timeline. In parallel, participants flag every observed problem, conceptual contradiction, and risk with red or purple notes rotated 90 degrees (Hot Spots).
5. Discussing domain boundaries — participants group related events and give them business names, which lets the architect mark out the first candidates for Bounded Contexts. The session closes with a dot voting round (using arrows) to identify the most pressing areas that need immediate attention.

Results and Deliverables

The session produces a coherent, visual model of the organization's business processes and a full alignment of knowledge between business and IT. The architect walks away with a process map that clearly highlights Hot Spots, an initial definition of context boundaries (Bounded Contexts), and precisely defined implementation priorities — direct input material for the next, more detailed workshops.

The Strategic Transition: From Big Picture to Process Level

A natural mistake made by many project teams is to try to immediately detail the entire map produced during the Big Picture session. This quickly exhausts participants' energy and leads to analysis paralysis. From an architectural perspective, a selective approach is essential.

The IT architect analyzes the density of red notes (Hot Spots) on the overall diagram. The areas with the most identified problems, ambiguities, or the greatest business risk and technical complexity become the primary candidates for further work. Using the voting results, the team points to a single, key process of the highest strategic value. It is precisely this chosen process that is carried over to the Process Level, while simpler or non-critical areas can be modeled with standard analytical techniques without engaging a broad group of experts.

Process Level Event Storming

The Essence and Tactical Goals

The goal of Process Level Event Storming is a detailed, microscopic analysis of a single, selected business flow. The workshop focuses on fully understanding the process dynamics, the business rules, and the interactions with users and external systems. The method is used when designing new, complex features, analyzing integration processes, preparing a precise development backlog, and as the direct step preceding technical code implementation.

Metadata: Process Level Session Setup

Process Level Artifacts

At this level the visual grammar expands considerably in order to depict the interactions taking place inside the system. New, precise elements representing the dynamics of the software are introduced.

How a Process Level Workshop Unfolds

A tactical-level workshop demands a precise facilitation approach and a focus on the logical connections between elements.

1. Reconstruct the events — accurately recreate the sequence of Domain Events for the sub-process chosen from the Big Picture level, taking care with the precision of the vocabulary and eliminating inconsistencies.
2. Add commands — before each domain event, place a light-blue command note (Command). A command represents the direct request of a user or external system that leads to that event occurring.
3. Assign actors — each command gets an actor (a small yellow note) with the authority and intent to issue it. If a command is triggered automatically, the actor is replaced by an external system or a policy.
4. Describe policies — identify and precisely describe the business rules with purple policy notes (Policies), written in the reactive pattern: "Whenever [Event] happens, then execute [Command]".
5. Design read models — place green notes (Read Models) under the commands, defining the data and views that must be presented to the actor on screen so that they can decide to send a command.
6. Model exceptions and verify — analyze exceptional situations and compensating processes ("what happens if the payment is rejected by the external system?"), modeling alternative paths with additional commands and events, then verify the whole model with a reverse narrative.

Results and Implementation Readiness

The result of a process-level session is a complete model of the business process flow, free of logical gaps. The development team gains an unambiguous understanding of the exceptions, integration dependencies, and business rules, which makes it possible to immediately begin designing the software architecture and precisely splitting tasks in the backlog.

The Most Common Facilitation and Design Mistakes

Running Event Storming workshops demands high attentiveness from the facilitator and architect to the group dynamics and adherence to the method's rules. The most common mistakes include:

• Escaping into technical detail too early — developers and architects have a natural tendency to talk about databases, API structures, JSON, or cloud technologies. This blocks communication with business experts, who stop following the meeting, completely destroying the value of building a Ubiquitous Language.
• Discussion dominated by one person — allowing a technical lead or a dominant manager to impose their point of view paralyzes the activity of everyone else. The model then stops reflecting reality and becomes merely a reflection of one person's imagination. This is why individual work and silent sorting techniques are crucial.
• Overly detailed analysis at the Big Picture stage — trying to draw out commands or views for the entire enterprise in the first meeting quickly exhausts the team's energy and fails to achieve the strategic goals.
• Absence of key business representatives — modeling processes solely with the IT team entrenches incorrect assumptions and produces a system that does not match real business needs, creating legacy software from day one.
• Treating Event Storming as a BPMN diagram — trying to impose the rigid notational rules known from BPMN at an early stage limits the creativity and flexibility of the workshop, turning it into a formal, boring analytical meeting.

What Comes After Process Level?

Producing a coherent process model at the tactical level is the direct foundation for entering the Design Level Event Storming stage and the physical design of software systems. At this stage the team's attention shifts directly to the technical elements of the software.

The precise boundaries of Aggregates are identified — the business objects that must preserve data consistency within a single database transaction. API contracts and Bounded Context boundaries are defined, translating directly into the structure of modules in the code or the boundaries of microservices.

The precise separation of commands (the write side) from read models (the side presenting data) provides clear, well-justified architectural arguments for adopting CQRS (Command Query Responsibility Segregation) and Event Sourcing patterns, if the complexity of the domain requires it.

Summary and Conclusions

Event Storming is not a method for automatically designing software architecture, but it is a key tool for shaping that architecture consciously. The Big Picture workshop gives the architect the necessary strategic context and an understanding of the entire business domain. The Process Level, in turn, descends one step lower, enabling a thorough understanding of a specific process and its business rules. A conscious IT architect knows that stable, flexible, and scalable software architecture always begins with a shared, deep understanding of business processes and the construction of a common language — not with the choice of technology or databases.

Comparing the Levels of Event Storming

The table below compares the two key levels of Event Storming from the perspective of an IT systems architect.

Event Storming pairs naturally with the rest of the Domain-Driven Design toolbox. If you want to see where its outputs lead, continue with Strategic DDD (Bounded Contexts and Context Mapping) and Tactical DDD (Aggregates, Domain Events, and the building blocks that turn the model into code) in the Architecture section.