Event storming

Lately I've spent some time catching up on what's happening in the Domain-Driven Design (DDD) community through watching sessions recorded at the Domain-Driven Design Europe 2016 conference. The session I watched yesterday was about something called event storming - a concept that was new to me but so simple and seemingly powerful that it got me quite worked up. The purpose of this blog post is not to go into details of how event storming works, but rather to convey my initial thoughts of why the idea is worth thinking about.

When running an event storming workshop you only need a few basic things:

• post-it notes with different colors
• a lot of space to place the post-it notes on (e.g. a large whiteboard or a paper roll)
• the right people

The right people are key in event storming and should involve a moderator, developers, domain experts and other people involved that can contribute when storming away at the problem at hand.

Domain events

With all these smart people gathered in a room, you start with identifying a few core domain events. A domain event is formulated as something important that happened in the domain under analysis, e.g. "ticket purchased" or "seat reserved". As you can see, domain events are always expressed in past tense. Each domain event is written down on a post-it note with a specific color - the resources I've found online so far suggests orange stickers by convention - and placed on the whiteboard from left to right in order of occurrence in the business process we are analysing. This means that we get a visual representation of the business process flow to see when the various domain events occur.

Commands

During the identification of domain events we also need to ask ourselves how they are triggered. For instance, the domain event "ticket purchased" might be a consequence of a user placing an order via a web application. The act of placing an order is, in event storming terms, a command. A command is something that generate domain events which we express through blue post-it stickies. Commands are formulated in present tense, e.g. "purchase ticket", and placed on the whiteboard just before the domain event(s) that are generated as a result of the command. For example, a "purchase ticket" command should probably be placed just before the "ticket purchased" domain event to signal that they belong together.

The flow of the workshop

With the two core concepts of commands and domain events, the participants of the workshop keep exploring the problem area to gradually refine and expand it. As the notion of event storminig stems from DDD, we take extra care to capture the "ubiquitous language", i.e. we want to make sure we are naming things so that it makes sense for the business problem we are trying to solve. Participants in the workshop are encouraged to question things, no matter how trivial they may sound. Is "ticket" really the correct word? Is it to general?

It is during the ongoing discussion, with post-its being replaced and moved around, we hope to nail the complexity of the domain problem. Suddenly, a domain expert states that there should be a way to reserve tickets. And by the way, you should be able to get a refund if you cancel your ticket purchase within a given amount of time. The complexity of the problem gradually reveals itself, captured in a process time flow and grouped by commands and domain events on a whiteboard covered with colored post-it stickies.

What do we get out of this?

It should be noted once again that I've not actually tried this workshop format, but in my mind it really makes sense. The idea is super simple and the potential outcome of it is interesting in several ways. First and foremost, we can express the components of a problem we are trying to solve (and how they relate to each other) with terminology that comes directly from the domain experts. Another neat thing is that commands and domain events map really well to implementation. They are a natural fit for CQRS and event sourcing, but when you think about it, commands and domain events can be mapped pretty well to any kind implementation technique. Something triggers an action (command) that produces some kind of result (domain event).

Final notes

Event storming include more stickies for e.g. highlighting actors, UIs and domain models. Moreover, as we are in the DDD world, we can map related commands and events to a particular aggregate and express that directly on the whiteboard by simply grouping them together. The same goes for bounded contexts; to group aggregates into a bounded context you just draw a line around the involves post-it stickers with a whiteboard marker.

For those of you versed in DDD, we can start drawing a context map from here, but that's the topic of a blog post for a later time.

This blog post was authored by Martin Moberg.