Event-Storming¶
This guide introduces Event-Storming as a collaborative modeling technique for discovering and designing events in event-sourced systems. It explains the purpose of Event-Storming, how it fits into the software development process, and how it helps identify meaningful domain events that form the foundation of systems built with EventSourcingDB.
Event-Storming is not a technical activity — it is a domain-centric workshop format. Its goal is to surface domain knowledge by bringing together people with different perspectives: developers, product owners, designers, and domain experts. At the center of this process are domain events — descriptions of things that have happened in the business and that matter to its operation.
Discovering Events Through Conversation¶
In traditional software design, requirements are often gathered in a linear, document-driven way. Event-Storming turns this process on its head: instead of capturing behavior through specifications or use cases, it invites participants to describe what happens in the business — in their own words.
These statements become candidate events. Examples might include:
- A customer placed an order
- A payment failed
- A user was added to a group
- A book was borrowed
By collecting and organizing these domain events visually, a shared understanding emerges — not just of the system, but of the business itself. This shared language becomes the backbone of event modeling and system architecture.
From Sticky Notes to Domain Models¶
Event-Storming is typically done on a large surface (physical or virtual), using sticky notes to capture each event. Events are written in past tense and placed from left to right in the order they occur. This timeline-like structure helps uncover flows, dependencies, bottlenecks, and missing steps.
Once the core events are in place, additional modeling elements can be added:
- Commands (what triggers the event)
- Actors (who or what issues the command)
- Aggregates (what enforces business rules and emits the event)
- Policies (reactions that trigger further behavior)
- Read models (information needed for decisions)
These are not mandatory — many teams focus solely on events in the first iteration. What matters is that the process starts with the domain itself, not with technical concerns.
Connecting to Event-Sourced Systems¶
Event-Storming is particularly effective when designing event-sourced systems, because it mirrors the way such systems operate: state is derived from events, not stored directly. By starting with events, the modeling process aligns naturally with the resulting architecture.
Each event discovered during the workshop can become a candidate event type in EventSourcingDB. Its name, structure, and context are already grounded in the domain. This reduces the gap between design and implementation, and improves the quality of the resulting system.
At the same time, not every sticky note needs to map directly to a stored event. Some may describe transient behavior, external interactions, or internal decisions that are better modeled as commands or policies. The goal is not to implement every event — it is to identify the ones worth persisting.
Making Events Explicit and Meaningful¶
A key benefit of Event-Storming is that it helps teams avoid vague or generic events. When participants describe what really happens in the business, the resulting event names are often rich and expressive — invoice-issued, account-locked, shipment-delayed. These are far more useful than technical artifacts like user-updated or status-changed.
This expressiveness makes the event log more valuable: it tells a story, supports analytics, and reflects the language of the business. In EventSourcingDB, these events become the durable foundation of the system — and they remain meaningful long after the code around them has changed.
When and How to Apply Event-Storming¶
Event-Storming is most useful early in the design process, when the goal is to explore a domain or understand a new feature. It is especially powerful when:
- Starting a new project
- Onboarding new team members
- Refactoring a complex area
- Designing an aggregate or bounded context
- Preparing for schema and event modeling
Workshops can last anywhere from one hour to several days, depending on scope. Some teams use short, focused sessions to model specific workflows. Others run large-scale workshops to map entire domains. The format is flexible — what matters is the shared exploration and visual feedback.
Aligning Language Across the Team¶
Because Event-Storming centers on events as shared language, it promotes alignment between roles. Developers, analysts, testers, and stakeholders participate as equals, contributing different views of the same reality. This reduces miscommunication and reveals assumptions early.
The resulting event names, commands, and aggregates often become part of the ubiquitous language of the team — used in code, documentation, and conversations alike. This alignment is especially valuable in event-sourced systems, where small ambiguities in event modeling can have long-term consequences.
From Exploration to Implementation¶
Once an Event-Storming session has produced a clear picture of what happens in the domain, the next step is to distill the relevant events into concrete types. At this point, teams move from the whiteboard (or virtual board) to defining event type names, subjects, and schemas in EventSourcingDB.
Not every sticky note becomes a persisted event. But those that do are well grounded in domain understanding — and already carry meaning, context, and consensus.
By starting with Event-Storming, the event modeling process becomes less speculative and more collaborative. It builds confidence, improves design quality, and creates better alignment between the domain and the system.