What is Event StormingEvent Storming is a workshop format for quickly exploring complex business domains.
It is powerful: it has allowed me and many practitioners to come up with a comprehensive model of a complete business flow in hours instead of weeks.
It is engaging: the whole idea is to bring people with the questions and people who know the answer in the same room and to build a model together.
It is efficient: the resulting model is perfectly aligned with a Domain-Driven Design implementation style (particularly fitting an Event Sourcing approach), and allows for a quick determination of Context and Aggregate boundaries.
It is easy: the notation is ultra-simple. No complex UML that might cut off participants from the heart of the discussion.
It is fun: I always had a great time leading the workshops, people are energised and deliver more than they expected. The right questions arise, and the atmosphere is the right one.
How does it workHere are the basic steps:
- Invite the right people to the workshop. Ideally you’ll want a large meeting room with 6..8 people, with the right mixture of the ones who know the questions to ask (and which are curious to listen to the answer) and the ones who know the answers.
- Provide unlimited modelling space. Too often complex problems are not properly analysed because there’s not enough space available to see the problem. Your problem is bigger than your whiteboard, so what? My solution is to hack the modelling space using whatever available (my favorite tool is an Ikea paper roll) to get rid of the space limitation.
- Explore the domain starting from Domain Events. A Domain Event is something meaningful happened in the domain. It can be easily translated into software, but the real value here is that it could be quickly grasped from non technical people. An event might be the predecessor of the follower of another one. Place all of them onto your modelling surface (the convention is to use orange stickies for this purpose) according to a timeline.
- Explore the origin of Domain Events. Some events are the direct consequence of a user action —> represent it as a Command using a blue sticky note. Others are the consequence of something happening in external systems or of the time passing, we’ll use a purple sticky note for them. In some other cases, we’ll have events that will be the direct consequence of some other events. We’ll simply place the two events close together.
- Look for Aggregates. Instead of defining aggregates starting from the code, we’re taking an outside-in approach: the Aggregate is the portion of the system that receives commands and decides whether to execute them or not, thus producing a domain event.
Bonus targetsThese are the basic steps of the original EventStorming format. However, you might spot some bonus goals along the way, if the discussion becomes hot. Here’s a list of the possible bonus targets which are worth considering as a rewarding detour from the standard route.
- Exploring Subdomains: some domain experts will show more expertise in an area, leaving other portions of the domain to others. Different areas of responsibility map pretty well to different subdomains or portions of the pork if you’ve been exposed to my presentations in the past.
- Exploring Bounded Contexts: during the discussion, some conflict areas might emerge. Developers and facilitators with a DDD mindset will spot different interpretations of terms, as a trigger for discussion around the meaning. This might be a good moment to draw the boundaries between the multiple consistent models that will coexist in your domain.
- Sketching User Personas: when talking about commands, conversation tends to steer towards the context where the command is issued and the goals of the person triggering the action. This is valuable information, don’t blow it! You may expand the notation to include little yellow sticky notes as personas.
- Sketching Key Acceptance Tests: if the discussion starts revolving around corner cases or ambiguous scenarios, there’s no better way to remove ambiguity than to define a clear acceptance test. Not all scenarios will need to be documented in such a way (I mean not in this workshop, mostly for time reasons) but if they’re a tie breaker in some areas there’s no reason not capture the emerging knowledge right now.
- Sketching Key Read Model Artefacts: for some scenarios what the users see if far more important than what the system does. If a screen, table or graph particularly valuable to a given user, just sketch it in a sticky and place it close to the command it is associated to.
Choosing the right format
Turning the model into code
You’ll be basically implementing the right thing faster.
How do I start doing EventStorming?Running an experiment isn’t that difficult. All you need is:
- a suitable room, quiet and large enough to contain the modelling surface (if the weather permits, outdoor modelling might be an option too, but wind might be a major blocker);
- a writable surface, most likely an Ikea paper roll (codename Måla, you can find it in the kids area).
- a LOT of sticky notes, in different flavours (the basic set is pale yellow rectangular stickies, plus orange, blue, and purple squared ones);
- working markers, ideally one per participants plus backup;
- some masking tape, just in case;
- the right people.
- a facilitator.
What’s next…While practicing and experimenting with EventStorming, I realised that I’ve stumbled upon something bigger. I tried to tell the story of what happened in the past month in this presentation. I called Model Storming the more general approach I am now applying, with EventStorming being just the most notable implementation.
More about it will come soon. This stuff is too cool to keep it only for myself! ;-)