Event Storming

Introduction

The team was given the task of developing a new CRM system within a certain time frame. As mentioned before, we have decided to explore the CRM domain by using event storming. Event Storming is a communicative method in which knowledge and understanding about a specific field of knowledge (domain) is developed and visualized jointly and across disciplines in a workshop. The starting point is so-called domain events.

Setup

The role as moderator of the event storming workshop was taken by the project manager and team leader; Adam. The participants were the team members; Jack and Alexander; business analysts and CRM domain experts, Ben, Clara and Julia; different level developers to achieve already a common understanding at this early stage.

Initially, Adam introduced the idea and process of event storming to the participants. Also, the specific context and goal of the workshop was explained.

Preconditions

Before we can start, Jack suggested that we should set the colour codes to be used in the workshops. Therefore we agreed on the following

• Orange colour indicates the events which represents a completed action. Usually it is represented in the past tense, example: Customer created.
• Blue colour indicates the commands which represent the event trigger. Usually it is represented in an order format, example: Create_Customer.
• Green colour indicates the read models which represent, for example, something that the user needs to be displayed on the screen. But it is not just data, but the data required for decisions to take place. Example: Customer master data, reason for contact etc.
• Pink colour indicates external system which can represent an interface to any other system that feeds our system with inputs. Example: Employee Personal data.
• Yellow colour indicates the users involved in a certain event in the system.
• Grey colour indicates the aggregates.

Steps

The below will explain the event storming procedure.

First a virtual (digital) whiteboard for our event storming session was created. Julia recommended that we should not hold the workshop with post-its on a wall as originally intended, but to hold it digitally. The reason for this was in particular the simpler processing and documentation of the workshop results. The meaning of the individual colours of the notes was explained to the participants. Also, what to do in the workshop was explained.
Then, participants were asked to write the domain events they could think of in the CRM context on sticky notes and to put them on the digital whiteboard. Afterwards, Ben sorted the identified events chronologically with the help of Adam. Domain events that were not clearly named for all participants were also discussed and corrected if necessary, and duplications were eliminated. Once we had ordered the domain events from left to right, together we identified the commands that triggered the events along the timeline. At this step, Alexander hinted that we need to also add the users who triggered the commands and other systems involved at some points. These were supplemented in some places with sticky notes for the Read Models to describe what information was needed in some places.

At this point, all relevant events, including associated artefacts, e.g., commands, were identified and we moved on to categorize them.
The first lowest level of categorization is the aggregates, which are entities or groups of them that are treated as one. Also, commands and events are directly related to them. After the discussion, we discovered four aggregates in the event storming, which took us to the next level we had to decide on, the bounded contexts. We strived to eliminate dependencies across bounded contexts as much as possible. So tightly related events should be in the same bounded context. If the language changes between events, then that is a sign that you have crossed into a different bounded context.

Finally, we identified two bounded contexts for our CRM (apart from the external systems).

Event Storming Outcome

Below, you can see the full event storming outcome.

Looking into the details, lets go through the outcome.

Domain Events

Domain events identified were

• Customer created
• Customer updated
• Customer activated
• Classification added
• Classification archived
• Contact added
• Responsible added
• Responsible removed
• Customer deactivated
• Customer deleted
• Contact created
• Contact updated
• Contact deactivated
• Contact deleted
• Minutes created
• Minutes updated
• Minutes released (changed from Draft to Final)
• Minutes deleted
• Participant added
• Participant deleted

Users and External systems

• Users
  • CRM User
• External systems
  • Party management system
  • Employee management system

ℹ️note

To focus on the most important outcomes, commands and read models were left in this summary out. Also we did not explore attributes (properties) of all the entities at this step.

Best Practice

• Since colour notation differs depending on the source you are reading about event storming, it should be defined and communicated in advance of the event storming workshop.
• Think carefully about the group of participants beforehand. In particular, more than one subject matter expert is needed.
• The modelling space should be unlimited (especially when doing the event storming physically).
• Using a a digital whiteboard, a too large number of participants can be difficult to handle.

Achievements

The most valuable achievement of the event storming is in our opinion

• A common understanding of the discovered domain.
• Identifying the bounded contexts.
• Identifying aggregates.