# EventStorming

> A collaborative workshop method for discovering how a domain behaves by mapping events and the forces around them.

- HTML version: https://robbiepalmer.me/ideas/eventstorming
- Source: https://www.eventstorming.com/

EventStorming gathers the people who understand a domain and asks them to build a shared timeline of
things that happen. The first artefacts are domain events, usually written in the past tense. The
group then adds the commands, actors, policies, external systems, and trouble spots that explain why
those events occur.

The oversized, messy timeline is the point. Conflicting terms and missing transitions become
visible while the people who can resolve them are in the room. The method can expose bounded
contexts and candidate services, but it should not jump straight from sticky notes to a database
schema.

I like EventStorming when interviews produce tidy descriptions of a process that everybody knows is
messy in practice. Exceptions, delays, and arguments are often more informative than the happy
path.

## A useful starting rule

Begin with events and resist premature structure. Let the domain reveal where the boundaries are.

## Related ideas

- [Domain-Driven Design](https://robbiepalmer.me/ideas/domain-driven-design.md): Model software around the language, rules, and boundaries of the problem domain.

---

Markdown index of this site: https://robbiepalmer.me/llms.txt