In the context of Domain-Driven Design (DDD), Event Storming is incredibly useful and valuable, Dan North claimed in his presentation at the recent DDD eXchange conference in London, explaining the basic mechanics of Event Storming and sharing his experiences from modelling different systems during the last few years.
Event Storming is a meeting where all the key stakeholders get together in a room with a lot of modelling space and use stickies to describe what happens in a system. An orange sticky represents a Domain Event- a statement in past tense about something that has happened. North always starts at the end with the last event, because it keeps him focused on the goal. He then adds the first event, creating a timeline all the way from the beginning to the end.
Other common stickies include:
- An event is caused by a Command and modelled with a blue sticky. Commands can be started by people, external events injected into the system or by a timer.
- Questions and other issues are modelled with pink stickies.
- When people describe what they see or expect to see, North often models this as a view or a read model using green stickies.
North notes however that this method is not prescriptive; he recommends to use what works for the situation you are trying to model.
According to North, the real power in Event Storming comes from the modelling of outcomes. We are interested in what has happened, which creates options for the way things could happen. We have traditionally been modelling around processes, activities and things that people do, but this tends to be quite constraining because we often end up starting with what people do. If we instead focus on the outcome of these activities, modelled as events, we get more optionality.
The reason Event Storming is so effective is because a lot of useful work is done in parallel. Most people focus on the part they are working on daily which creates groups of people working with different parts of a model. Often this produces clusters within a model which may be aggregates or subsystems. Those who know the whole process, such as managers, adopt a broader view and check that everything hangs together.
One important step when modelling is asking which events are necessary: events that absolutely must happen in order to get to the outcome, as opposed to events that just happen as part of the process but do not affect the outcome. This question may significantly simplify the whole process by removing unnecessary things.
North notes that Event Storming fits well in the same space as Impact Mapping, Story Mapping and other collaborative discovery activities. He uses Event Storming to build a shared understanding, then uses Impact Mapping to get a sense of direction, and finally uses Story Mapping for finding out how to implement and deliver an application.
Vaughn Vernon in an earlier presentation described Event Storming as an important tool for finding bounded contexts.
Alberto Brandolini, the creator of Event Storming, is currently writing a book: Introducing EventStorming.
Next year’s DDD Exchange is scheduled for late April 2017 and registration is open.
