# 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 event-sourced systems. **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**. 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**. Stored in the event store, 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**. 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. ## Capturing the Result in a Written Model The output of an **Event-Storming** session is **valuable knowledge** – but **sticky notes don't survive the next office move**. Once you have a clear picture of events, commands, aggregates, and policies, **capture the result in a written model** so it stays alive after the workshop. A written model **bridges the gap** between the workshop board and the **event types**, **subjects**, and **schemas** you'll later implement. > **Try it with ESDM** > > **[ESDM](https://esdm.io/)** – the **Event-Sourced Domain Modeling language** – is built for exactly this step. It expresses **events**, **commands**, **aggregates**, **process managers**, **read models**, and **context mappings** as plain YAML, and it ships with a linter that catches naming and structural issues early.