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 two EventStorming workshops (trial and case study), 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,
you first need to prepare a trial workshop with the other course members. This trial should be followed by a retrospective, where you analyse what went well and what could be improved. Before that trial workshop, you need to do the following:

1. Think of a suitable domain for your trial workshop. It should be a domain that is not too complex, but also not too simple. The course members should be familiar with the domain, so that they can act as experts and focus on the method. Something from university life might be a good choice.
2. Familiarize yourself with the available sources on EventStorming, esp. the books by Brandolini and Rayner, and the ressource collection by Gil.
3. Fully understand the central DDD concepts listed above, and prepare to explain them to the other course members.
4. Write a workshop concept where you define which elements of a Big Picture workshop you want to include in your trial. 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.
5. Plan and conduct the trial 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.
6. The other course members need be familiar with the central DDD concepts listed above before the workshop.
7. 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.
8. Document the trial workshop results, also to be included in your final paper. Think about an appropriate documentation format.
9. Plan, conduct, analyse, and document the case study workshop based on your experience from the trial.
10. Write chapters in your final paper that describes your workshop concept, the trial workshop, the retrospective, and the trial workshop results. The paper should be written in a way that it can be used as a guide for other course members who want to conduct an EventStorming workshop.

Sources

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