In previous chapters, we learned how important it is to understand the actual problem. We also went deeper into the concept of Ubiquitous Language and discussed that it is not only a glossary of terms but also the system behavior described in words.

It remains unclear how to start the knowledge crunching and how could we intensify our communication with domain experts to understand the problem space better and get a proper overview of what are we going to build.

Very often we see that developers get to know the domain in the form of requirements. We already went through this topic, and by now you should realize that requirements have their flaws. Then, you want to improve your knowledge by talking directly to domain experts and organize a workshop or meeting with them. Some people come, and you have a conversation for two or three hours, a lot of things get discussed, a lot of new insight comes to the surface, but there is a minimal outcome in the form of any modeling artifact. Surely, you could start drawing UML diagrams, but what business person would understand them? You could take notes to find out that you need a round or two of clarification workshops because there are too many vague and implicit concepts that form the foundation of your future system and this makes it very hard to understand.

There are a few fundamental issues we need to be solved here:

• Provide visibility during the discussion. It should remove assumptions when more people are discussing the same thing with different terms. It also eliminates some degree of ambiguity and brings it to the surface for further exploration.
• Have a modeling language that people understand. Clearly, UML is not an option, and usual boxes and arrows have no real notation so people can get confused and start spending time trying to clarify the meaning of things.
• Involving many people simultaneously. In traditional meetings, only one person can effectively deliver the message, while everyone else needs to shut up and listen. As soon as many people start talking at the same time there is no conversation anymore. But, assuming having people with different interests and background present in one session, they might show a lack of interest and get bored.
• Find a way to express both terms and behavior and model processes and decision, not features and data.

Back in 2013, Alberto Brandolini formulated a method that he called EventStorming, where he tried to address these issues. We are going to learn about this method in this chapter.