Event Storming – the first step towards DDD?

Event Storming is a way of discovering and concretising information about the business domain in which software operates. The day-to-day work of software developers and technical experts involves operating in numerous business domains. Retail, Telecommunications, Finance, Education, Law, Medicine – you name it. And often switching from one project to another means switching to a different business domain as well. So how can you gather all the information required to design high-quality software if you have no or little knowledge of a given business domain? One possible answer might come in the form of Event Storming and the correlated concept of Domain-Driven Design (DDD). This article goes from the Event Storming must knows, to the benefits of using it, to a step-by-step Event Storming flow, shown on the example of a workshop run at FIS-SST by our R&D team. 

The basics of Event Storming

Who’s involved?

An Event Storming workshop usually lasts a few hours and involves the following participants:

  • Technical experts, like software developers, analysts and product owners.
  • Domain experts representing the client.
  • Facilitator – a person familiar with Event Storming, who ensures a swift and proper flow of the workshop.

What’s it all about?

The idea of the workshop sounds quite simple. You need a board or a wall and lots of sticky notes in different colours. Every participant identifies the so-called “Domain Events”: actions that take place during the execution of the software, like for example “User account created”, “Item ordered” or “Invoice issued”. You write down these events on the sticky notes, which you then put on the board.

As one can notice easily, the Domain Events mentioned above are described using general, quite simple terms. This is because in Event Storming you are supposed to avoid using complex, specialized terminology. The goal is for everyone to understand everyone else, while using the terms that function in a given business domain.

Domain Events are triggers for further questions. What needs to be done for the “User account created” event to take place? The application needs to receive some kind of signal. So in Event Storming terminology, it needs a “Command”. The Command might be expressed by a statement like “Create user account”.

But who or what issues the Command? Does the user create the account on their own, through a registration process? Or is the user account generated automatically, based on some information received from an external system? This way we reach another element that needs to be identified during the workshop – the so-called “Actor”, responsible for triggering the Command.

The Commands and Actors also need to be represented using sticky notes. And so, one by one, the stickies get attached to the board where the beginnings of a software model are formed. At a later stage of the workshop, functionally correlated elements are grouped to form the so-called “Aggregates”.

The advantages of Event Storming

Understanding the domain

Event Storming eases the transfer of knowledge between technical experts and domain experts. You do not talk about databases, frameworks or object-relational mappings. Instead, you use domain-related terminology. As a result, the technical experts get familiar with the domain they operate in, while the domain experts gain a deeper understanding of how the given software works.

Introducing ubiquitous language

As an intersection of business and programming, Event Storming allows you to unify the language used while working with the client. And ubiquitous language is the basis for introducing Domain-Driven Design principles into your project.

Accelerating processes

In the case of new projects that are just starting, Event Storming might be an alternative to other, longer processes of initial planning. In Event Storming you run one, several-hour long workshop for representatives of different teams involved in product planning and you do so at an early planning stage, which might be more beneficial than discovering particular product requirements once development has already begun.

Sharing knowledge

Event Storming facilitates sharing knowledge both within and outside of particular teams. And transferring knowledge between various people involved in creating software prevents information silos from arising. This creates more learning opportunities for technical specialists and allows them to be more involved in the project, leading in turn to a more secure, perhaps even uninterrupted flow of work in the event of any changes in personnel.

Providing quality

Event Storming leads not only to a greater understanding of the business domain, but also to an in-depth analysis of dependencies between particular software functionalities. And a complete, domain-embedded understanding of processes occurring within the software is one of the factors that determines its high-quality.

Identifying problems

Long-running projects may also profit from introducing Event Storming, as it can become a problem analysis tool used for eliminating bottlenecks.

Integrating the team

Event Storming eases team integration by providing opportunities for group learning. Afterall, conversation and cooperation between many parties lie the heart of Event Storming. And for the employees who start working on a given project, participating in an Event Storming workshop might be an alternative induction method.

Event Storming step by step

At FIS-SST, as the R&D team, we run our own Event Storming workshop. We started with thorough preparation, learning about both Event Storming and the Domain-Driven Design principles for creating quality software. We read multiple long articles, watched presentations from various programming conferences and familiarized ourselves with a book by Alberto Brandolini, the creator of Event Storming. Finally, we were ready to start the workshop! And now we want to share the knowledge and experience we gained.    

How do you start the workshop?

We needed a large wall, some electrostatic paper and a lots of electrostatic sticky notes in different colours. We left our chairs at the desks – there is no sitting down in Event Storming. We set ourselves a goal of designing a brand new app, the development of which has not started yet. The domain we chose was Retail.

Step 1: Domain Events

Picture 1: Domain Events (in orange) with additional pieces of information (in yellow).

Domain Events were the heart of the workshop and the starting point for the entire business model we were to design. We needed to define the actions that were supposed to occur during software execution.

And what are the Event Storming guidelines for defining Domain Events? The events need to be relevant for business domain experts and they need to be expressed using past tense.

Each of us proposed some event examples that followed these guidelines, we discussed the examples briefly, noted them down on orange stickies and placed them on the wall. Some of the events we created are: “User authorised”, “External order placed” and “Balance changed”. We decided to place the events on the wall in the order in which they occur as the app runs – the result as a timeline of sorts. We then walked through the timeline backwards – starting from the last event and continuing until the first one, we checked whether all relevant domain events were covered. It was time to add Commands.

Step 2: Commands

Picture 2: A Command (in blue) assigned to an event.

We had to determine what actions initiate the identified events. To do so, next to most of the Domain Event stickies, we placed new, blue stickies that represented Commands. We noticed that in many cases the Commands were expressed using wording that was really similar to that of the corresponding events. For example, we assigned the “Authorize user” Command to the “User authorized” Domain Event. We knew that in some time, during the development process, the Commands will become methods written by us. However, that was not the time to be thinking about coding. Afterall, we did not know yet who or what was responsible for triggering these commands. And that was the right moment to determine it.

Step 3: Actors

Picture 3: A Command (in blue) with an Actor assigned. In this case the user is the Actor.

In a simple scenario, a Command is initiated by a user. As a result, the user is identified as the Actor. In many cases, while we were writing down Commands, we immediately knew that the user would be the Actor – we therefore marked it on the sticky notes right away.

However, some Commands were not as straightforward. They led to further questions regarding the way the designed software was supposed to work. For example, we wondered how to handle bans on creating new orders that we wanted to impose on select users. What should initiate such a ban? Another event? Or the passing of a time interval?

In accordance with Event Storming guidelines referring to the ways in which Domain Events can be initiated, there are a lot of Domain Event triggers, like Commands (for example provided by the user), external systems, the passing of time, or even other Domain Events.

Once we finished adding the Actors, our timeline was complete. We could therefore take a decisive turn towards DDD and determine the Aggregates.

Step 4: Aggregates

Picture 4: An Aggregate (in green), with Domain Events and Commands grouped around it.

In the next step we completely destroyed our oh-so cherished timeline! We grouped stickies representing Domain Events, and the ones representing Commands and Actors to form new entities: Aggregates.

Some Aggregates were easy to identify, like the “User” for example. A new, green stickie with “User” written on it was placed on the wall. And all the elements related with the User as far as the domain is concerned, were moved towards it.

However, some Aggregates were a bit more tricky. And so, in the case of the “Settlement” Aggregate, which had a lot of stickies grouped around it, we decided to split it into two separate Aggregates, namely “User Settlement” and “Order Settlement”.

This way we reached the last step: determining which Aggregates are connected and should therefore be grouped into the so-called “Bounded Contexts”.

Step 5: Bounded Context

In Domain-Driven Design, the boundaries of Bounded Contexts are set by the boundaries of ubiquitous language.

How should you put the above statement into practice? Let us use the Retail domain as an example. When asked to define what a product is, the domain experts responsible for sales may form their response around a certain set of features of the product they sell. While domain experts who handle shipping and inventory will focus on completely different product features. As a result, technical experts (and development teams in particular) will be provided with two different definitions of the product. In the case of sales, the important features of the product will include the price and any applied discounts. Such features may be entirely irrelevant for shipping and inventory, where the major factors might be the dimensions of the product and whether or not the product is assigned to a particular warehouse and/or shipping location. Taking this into account, in code you will need to create two separate objects, like “SaleItem” and “InventoryItem”. Although both represent items, they belong to two different contexts.

So, how did we handle contexts during our workshop? Contrary to what first may come to mind, the aforementioned “User Settlement” and “Order Settlement” were not placed within the same context. We decided to assign “User Settlement” to the same Bounded Context where the “User” had already been placed. We followed a way of thinking quite similar to the example of items mentioned above.

Picture 5: The entire view of the wall, at the end of our workshop.

And that’s all?

Most certainly not! Event Storming can be much more complex and it may require many more steps, depending on the needs of a particular project. Also, there is no single, proper way of running an Event Storming workshop. The most important aspects are the final results of Event Storming and knowing in which situations Event Storming might be an useful tool.

You can use Event Storming just the way we did: for designing new, greenfield software. However, it can also be applied to legacy software. Event Storming is especially suitable for large, complex applications. Focusing on the domain may lead naturally to introducing Domain-Driven Design principles on your project.

By using Event Storming at FIS-SST, we have done more than create a starting point for the development of our new app. We have made sure that we share the same understanding of the scope of the app, the way it will work, and the functionalities it will have. And so we have seen for ourselves that just as the quote at the very beginning of this article reads: „in any Event Storming session of all different kinds, everyone knows what everyone else knows“.

Leave a Reply

Your email address will not be published. Required fields are marked *