Domain Storytelling is a collaborative modeling technique that highlights how people work together. Its primary purpose is to transform domain knowledge into business software. This purpose is achieved by bringing together people from different backgrounds and allowing them to learn from each other by telling and visualizing stories.
If you practice EventStorming, you might see some similarities between the two methods; no wonder – we consider them as members of a family of collaborative modeling methods. However, if all you have is a hammer, everything looks like a nail. Hence, having more than one modeling tool in your toolbox is a good idea.
In this blog post, we will answer the following questions:
For which purposes is Domain Storytelling the right tool?
Domain stories are created in workshops: While the domain experts tell their story in spoken language, one of the workshop’s participants—the moderator—records the story as a diagram made of simple icons, arrows, and text. This way the storytellers and listeners get another representation of the story, which helps to uncover misunderstandings, contradictions, and plot holes. All participants see how the visual recording evolves together with the story. This makes it easy to give feedback and to contribute.
In our experience, telling and listening to stories helps with the following:
- Understanding a domain
- Analyzing business processes for problems
- Talking about software requirements
- Designing viable, software-supported business processes
- Structuring and implementing business software
EventStorming has similar purposes, and yet there are situations in which we prefer Domain Storytelling:
- If the domain involves many actors (people or software).
- If we want to investigate how actors communicate and cooperate with each other.
- When to-be processes are to be designed, a common perspective emerges more easily from a moderated, sentence-by-sentence approach.
- If creating documentation is a goal.
- When the corporate culture is more suited to a moderated, structured approach rather than EventStorming’s brainstorming approach.
How is Domain Storytelling different from EventStorming?
The first thing you will notice is the different layout of the model. Domains stories do not follow a left-to-right timeline, because they need to show cooperation between actors. That works better with arrows because they show who is doing what with whom. The arrows are numbered to express a sequence of activities – the story. That is another difference: Each domain story is about one scenario.
The workshop is also different. In Domain Storytelling, iterations of storming (discussing the next sentence) and consolidation (recording that sentence) are much smaller. A designated moderator channels the participants’ input by modeling it. However, things are not as black and white as they seem. Domain Storytelling can be used in a cooperative mode, and some EventStorming practitioners switch to a single-modeler mode if needed.
Can I use EventStorming and Domain Storytelling in the same project?
- During big-picture EventStorming, you might come across parts of the process that are cooperative, i.e., several people or systems are actively involved. If these parts are critical to your analysis of a domain, you might want to go the extra mile to get another perspective on the process: You can model the cooperative part of the process additionally as a domain story.
- You can use Domain Storytelling to design a software-supported business process – what a piece of software should do. Then, for figuring out how the software should work, you can switch to design-level EventStorming. If you plan on using implementation styles CQRS and Event Sourcing, using EventStorming on design level is an obvious choice. If you prefer a “classic” domain model, you can continue with fine-grained domain stories.
Henning Schwentner
