EventStorming

Event Storming is a collaborative modeling and domain exploration technique developed by Alberto Brandolini. It’s primarily used to model and understand complex business processes, especially in the context of Domain-Driven Design (DDD).

• Method Description
  • Goal
  • How to do it
  • In Presence or Remotely?
  • Deliverables
• Central DDD Concepts
• How to tackle this in an Academic Course like DDD
• Sources

Method Description

Event Storming is a powerful technique for domain exploration, knowledge sharing, and system modeling. It’s particularly valuable in contexts where the domain is complex or not well-understood by the entire team.

EventStorming became a way more general-purpose tool than I anticipated, spanning from software development to organization design.

[Brandolini, 2021, p. ii]

Whether the goal is to write a piece of critical software for the organization, or to design the next implementation of a business flow for a startup, or to redesign a fundamental business process for an existing line of business, this means having a clear, shared understanding of the problem landscape and of the possible solutions. Our recipe to achieve this result is straightforward: Gather all the key people in the same room and build together a model of the current understanding of the system.

[Brandolini, 2021, p. 68f.]

Goal

The goal of an Event Storming workshop is to achieve a shared understanding of a business domain or process by collaboratively modeling its events and interactions. We will focus on the initial phase of Event Storming, the so-called Big Picture workshop, which is the most common and most important one.

A ‘big picture’ workshop is usually where I start with an organization, to get a high-level overview of the current landscape.

[Rayner, 2022, p. 65]

A Big Picture EventStorming is one single large scale workshop that involves all the key people that we expect to cooperate to solve critical business problems. If understanding the system is the crucial ingredient to choose promising solutions and eventually implement the right software, then learning as much as we can, before wasting money on the wrong initiative, is the way to go. In this workshop, we’ll build a behavioral model of an entire line of business, highlighting collaborations, boundaries, responsibilities and the different perspectives of the involved actors and stakeholders [[…].

[Brandolini, 2021, p. 69]

How to do it

How a ‘Big Picture’ EventStorming workshop is conducted is described in the [sources below. It should be noted that, although EventStorming is some kind of creative, coordinated chaos, the rules and principles are nonetheless quite strict.

I’ll be strict in being consistent with my notation, using a rigid color scheme (orange for Domain Events, magenta for Hot Spots, blue for Commands, and so on).

[Brandolini, 2021, p. ii]

In Presence or Remotely?

EventStorming profits enormously from being conducted in a physical space, with all participants in the same room. The reason seems to be that the room dynamics (participants being able to switch to another group at any time) depends a lot on “peripheral vision” - the ability to see what is going on in the room, and to decide whether to join another group or not. This is much more difficult in a remote setting, where you can only see what is going on in your own Zoom or Teams breakout session.

Brandolini himself has written a blog post about EventStorming in a remote setting. His reasoning is way more elaborate and detailed than the short summary above. His “sad summary” (his own words in ths blog post!) is:

At the current state of technology, I can’t see ways to have a decent (I am not even looking for comparable) experience for a Big Picture EventStorming. The remote format will be more painful, creating impediments that will prevent key people to contribute and ultimately delivering more pain and lower gain, possibly leaving in place exactly the blind spots that we aimed to discover.

[Brandolini, 2020]

So, basically for the remote version: “Don’t do it!”. This applies to the initial Big Picture workshop. The other, subsequent EventStorming workshop formats (which we don’t cover in the DDD course for time reasons) seem to have some chance on success, remotely.

Deliverables

After the EventStorming workshop, the team should have the following deliverables:

1. A workshop concept that can be used as a guide for other course members who want to conduct an EventStorming workshop. This workshop concept needs to address prioritization of elements, room planning, detailed time schedule, etc.
2. A visual map of the domain’s key events, commands, aggregates, and policies.
3. Identification of open issues: bottlenecks, inconsistencies, or areas of ambiguity.
4. Shared understanding and ubiquitous language among team members.
5. Clustering of events that can serve as a starting point for defining bounded contexts.
6. Results from a retrospective with both moderators and participants, documenting what went well, what could be improved.
7. A reflection by the responsible EventStorming team about the general strengths and weaknesses of this method.

Central DDD Concepts

The following concepts are central to this method, and need to be explained to the participants. The links point to the DDD glossary.

• Domain Event

How to tackle this in an Academic Course like DDD

This section contains advice for student teams responsible for this topic in the DDD course.

An event storming workshop requires some familiarity with the method, especially for the moderators. Therefore,
plan some time to read and discuss in your preperation team. Plan also a retrospective, where you analyse what went well and what could be improved. Before workshop, you need to do the following:

1. Familiarize yourself with the available sources on EventStorming, esp. the books by Brandolini and Rayner, and the ressource collection by Gil.
2. Fully understand the central DDD concepts listed above, and prepare to explain them to the other course members.
3. Write a workshop concept where you define which elements of a Big Picture workshop you want to include in your workshop. Be aware that you have limited time, so you need to prioritize what elements you want to cover. Make sure that the goal - clustering of events to identify bounded contexts - can be achieved. Use the literature (Brandolini and Rayner) and the ArchiLab cheat sheet as a starting point.
4. Plan and conduct the case study workshop with the other course members. There is a physical case (Koffer) at ArchiLab, stocked with suitable PostIts and other material, according to the ArchiLab EventStorming cheat sheet and shopping list, so you don’t have to buy anything.
5. Plan, conduct, and document a retrospective with the other course members. The goal is to identify what went well and what could be improved. The results of the retrospective need to be included in your final paper.
6. Document the workshop results, also to be included in your final paper. Think about an appropriate documentation format.

Sources

In the DDD commented literature list, there is a dedicated EventStorming sources list - please go through it.