Event storming solves all your problems

There are two patterns to build domain models – tactical and strategical. Tactical patterns focus on on building blocks of domains model (value object, entity, aggregate, domain event, design patterns like repository, factory, strategy). Strategic patterns focus on concepts, communication, definition of ubiquitous language (bounded context, context map, core and sub-domains).

And there are many ways to explore domain and build domain models. It’s not easy to gather that knowledge in one place. In my current company my team is responsible for extracting part of existing application into separate service. The problem we encountered was that the majority of the team didn’t know the selected bounded context. Our first approach was that everyone singly was responsible for digging into some small part of the code and explaining it to the rest of the team. But after that we still had fragmented knowledge, no idea how to put it together into one simple system (the idea was not only to extract but also to refactor the code). Finally we decided to conduct event storming. In few hours of meetings we all not only know what’s going on from business point of view, but we also were able to translate domain process into code architecture (more or less…, you know, it’s still in progress).

I fell in love with event storming because it’s visual and comparatively easy to understand. It’s not technical (domain), but easy way to the code structure. It builds common understanding of domain (ubiquitous language) by engaging everyone in discussion.

How does it work? We invite domain experts (“business people”) and developers¹ into one room where they gather their knowledge about domain in sticky notes on a wide wall by asking questions and answering for them. Everybody is involved into the process overcoming obstacles of “too expert” or “too technical” language. The business process is “stormed out” as a series of domain events which are denoted as orange stickies². It’s chaotic process, so it’s good to have somebody with facilitator role – the person responsible for making this chaos working.

Mostly we start with Big Picture Event Storming to see the project domain from above. Next we run into Design Level Event Storming when developers translate domain knowledge into code structure.