An example process from an event storming
Event storming is a workshop-based method to quickly find out what is happening in the domain of a software program. Comparing to other methods it is extremely lightweight and requires intentionally no support by a computer. The result is expressed in sticky notes on a wide wall. wikipedia 
YOUTUBE 1i6QYvYhlYQ Published on Oct 19, 2017.
YOUTUBE bXm8Cznyb_s Published on Jul 10, 2016.
**Worshop GOAL: How do we learn together fast?** Life-cycle of the whole business will emerge with a map of the underlying system behavior and highlights of related systems and people.
workshop structure
**Invite the right people** 6 to 8, some with The Right Questions, some with The Answers. The Right People are usually busy running the business. Want to ensure we make best use of their precious time.
**Unlimited modeling space** (and simple tools) room with a big wall, butcher paper or Ikea _(Måla)_ paper roll, variety of sticky notes, at least one working marker per person, masking tape.
**Start with _Domain Events_** written in past tense, on an orange sticky, quickly grasped by everyone, eventually organized on the paper chronologically.
**Explore the Origin of domain events** Action (blue sticky) started by a person or persona (yellow sticky), external systems (pink sticky), time passing (orange sticky), or maybe consequence of another domain event (orange sticky).
**Look for Aggregates** the part of the system that receives commands, decides whether to execute them or not, and emit _domain events_.
discovery opportunities
**Capture important business knowledge** Unknowns can be scary and derail a workshop. Capture them on dark pink stickies to direct future work or to identify risks. Policies can be captured on lilac stickies.
**Explore Subdomains** different domain experts can share the parts of the system they know well _(and show off their expertise, which is usually fun)_
**Explore Bounded Contexts** conflicting meanings for similar terms can trigger discussion to clarify meaning or draw boundaries to allow multiple models to coexist.
**Sketching Personas** Commands that trigger events can illuminate goals and motivations of the actor.
**Sketching Acceptance Tests** Corner cases and ambiguity can be clarified by defining acceptance criteria. Capture the emerging knowledge where there's energetic discussion. Careful to capture these opportunistically rather than drag excruciating detail out of every domain event.
facilitation
This is a discovery and learning process, not aiming for decisions. Develop shared understanding about what we know; what we don't know; what we disagree about; what concepts we might be missing; we need to learn and understand.
Build on each others ideas rather than correct each other. Collect the diverse perspectives for more complete understanding.
Timebox. Spend 20 minutes on this part and then stop and review what we've done. Include breaks when energy drops. Use timeboxes and breaks to create rhythm.
Post first. Ask questions later.
Anchor conversation in concrete business examples.
facilitating questions
What circumstances would cause this to happen?
What was the path that led us here?
What is a good example of ...? _devs think in abstractions, business people tend to be more concrete_
What do you mean by ...?
What else might happen here?
transform domain model to code
Event Storming leads quite naturally to a distributed systems architecture called Event Sourcing:
Design a system by modeling objects as a stream of events. Instead of saving the current state, save the events that lead up to the current state.
event modeling
Event Storming Workshop > We've replaced pair programming with mob designing. We've removed the elitist pattern of programmers being the only ones that get to design. It's why we use @EventModeling to build using a blueprint and navigate using a map.