EventStorming meets Domain-Driven Design with Alberto Brandolini: A workshop review

Domain-Driven Design (DDD) is an approach to software development for complex scenarios: scenarios where we cannot get to the right implementation at first attempt. This is far more common than one might think. Often, what we experience in software development projects on a daily basis, is the assumption that it is possible to build software systems based on reliable requirements. But this disregards both the fact that business needs constantly change and evolve over time and the reality of fragmented knowledge: Even only two business experts in the same domain will hardly ever have the exact same understanding of the problem they are trying to solve. In order to deliver true business value, we need to build software in ways, which allow and enable us to engage in a constant discovery process, rather than match an elaborate upfront design.
With DDD, everyone involved in the business can contribute to collaborative discovery: domain experts, software developers, stakeholders and customers.

Within a codecentric-internal 4-day workshop, a group of 10 software developers, architects and product owners had the chance to dive deep into the Domain Driven Design world, guided and supported by Alberto Brandolini, the inventor of EventStorming , a popular collaborative workshop format.

Needless to say, it is impossible to touch every aspect of a 4-day training, therefore I will focus on aspects of EventStorming, general learnings and the benefits of attending one of Alberto’s workshops.

EventStorming: A Brief Introduction

EventStorming actually refers to a family of workshop formats, which allow for collaborative exploration and modelling of complex business domains.

The following EventStorming workshop formats are distinguished and often used within the field of DDD*:

• Big Picture EventStorming:
  allows collaborative exploration of an entire business flow, looking for diverging perspectives and interests of the several stakeholders involved.
• Process Modelling EventStorming:
  focuses on collaboratively designing effective processes, leveraging a non-specialistic notation, in order to allow interdisciplinary collaboration of business, technical and UX-CX stakeholders.
• Software Design EventStorming:
  adds a level of depth on the previous format by exploring the moving parts of a software implementation of the solution and progressively injecting a more rigorous grammar.

On day 1, we started with Big Picture EventStorming. It involves a larger group of people (usually 10-15, but sometimes up to 30 people), who collaboratively explore everything that happens within a line of business by creating a timeline of events out of sticky notes on an “infinite” modeling area (usually a very long wall).

The Big Picture EventStorming helps to identify Bounded Contexts together with the dev team: Units of homogenous language and model consistency, which together form a heterogeneous whole. Within a bounded context, we define a Ubiquitous Language, where every term has exactly one, and only one, meaning. By designing our system out of bounded contexts, we can solve one problem at a time, without making our life harder than necessary by having to implement expensive compromises and trade-off solutions.

It is a good strategy to detect the core domain, and identify “bottleneck” candidates, whose improvement might significantly benefit the whole system.

Important to say: The result of a Big Picture EventStorming workshop is a large map of the group’s understanding of the business at the time of the modeling, never a final result. It can only be interpreted as a snapshot of the participants’ knowledge, and therefore serves as a starting point for further exploration, rather than a goal in and of itself.

Based on the Big Picture, we then rolled up our sleeves and went on with Process Modelling and Software Design on days 2 and 3, and even implemented hands-on a part of our model, using Event Sourcing with the Axon framework. If you are interested in a more detailed explanation of the respective phases, please see the following blog post (sorry, German only): Event Storming – Gemeinsam die Domäne entdecken .

General Learnings

Alberto’s training was my first contact with the DDD universe, besides some conversations with developer colleagues about this topic. It has been an intense four days, filled with a lot of information in a short amount of time. I would in no way call myself an expert in this field now, the workshop was a condensed first step into the topic and has sparked my motivation to learn even more. One key insight that will have a profound impact on my daily work is the distinction of domain types, and their importance to project implementation.

Eric Evans, thought leader in software design, domain driven design and domain modeling, states:

The heart of software is its ability to solve domain-related problems for its user.

(Eric Evans, Domain-Driven Design: Tackling Complexity in the Heart of Software). This means when developing software we should not primarily focus on technology, but rather on the business side, therefore the functional area which we would like to support: the domain.
DDD distinguishes between three types of domains*:

• Core Domain:
  What makes you special, the small portion of your expertise and software that gives you an edge on the market.
• Generic Subdomains:
  The ones which are necessary for your company to survive, but which are not intrinsically a competitive factor.
• Supporting Subdomains:
  Something which is not enough general purpose to be available off-the shelf, and needs to be developed in a custom way.

Understanding whether we are in the core or not is vital, it helps us make important decisions regarding investment and development effort.
In the core domain it is extremely beneficial to work with few internal developers that have a long-term understanding of the problem as well as easy access to key domain experts in order to foster a successful collaboration: more quality generates more revenues.
Besides, quality above a given level won’t turn into more revenues in supporting subdomains, which are usually cost-driven. If we are in the generic subdomain it is recommended to use an existing software solution as it won’t be much of a differentiator.

Learning about these different areas and their distinction increased my awareness
regarding what to focus on and what questions to ask in the future by a lot. In my role as a product owner together with the development team and domain experts, we need to ask ourselves whether the respective software development project is a game changer or if it is may just playing a supporting role. Although everything is important to the business, not everything is equally important.* DDD allows us to constantly learn about the business, and translate our findings into working software, which delivers true business value.

Benefits of attending a workshop with Alberto

I can highly recommend joining one of Albertos workshops. Not getting tired of our questions -and we had a lot- Alberto always came up with real-life examples that he himself had experienced. This made the training extremely enjoyable and insightful, but also the presented methodologies and practices applicable for the daily challenges that we often face as software engineers, architects and product owners.

In Alberto’s workshops you will not only learn about DDD and EventStorming, but also about collaboration, interpersonal connections, political issues in organizations and how to tackle them as well as frameworks and best practices.

One learning, which at first glance seemed like a no-brainer, but really had an impact on me, was the following statement:

It underlines the importance of simply taking a first step, starting with what you have and what you know at a given point in time, instead of giving in to the urge of modeling everything at once and upfront.

Our workshop was equally divided between theory and exercises, where the participants had the chance to apply the theoretical parts on real-life problems. In small groups, we worked together, had discussions, experienced typical group dynamics caused by different personalities and also encountered some moments of frustration. You may think that is something negative, but this is what I liked most about the 4 days: Alberto gave us the chance to really learn and get insights. He did not present a solution first-hand, but gave us the time and the support for figuring it out on our own. That is how you learn, right?

There aren’t a ton of articles and even less books on the market covering the topic of DDD and EventStorming, which makes it hard to gain a comprehensive view just by studying in private. So if you ever have the chance to see Alberto in action, take it – it is truly worth it.

*from: Alberto Brandolini: “Domain Driven Heuristics, Complementary info for the Domain-Driven Design Modelling class”, 08/2019