Use Model With Domain: An Interview on Domain Storytelling - EventSourcingDB

Skip to content

Initializing search

Getting Started

Fundamentals

Deployment and Operations

Reference

Client SDKs

Extensions

MCP Server

Best Practices

Implementation and Development

Data Management and Performance

Operations, Compliance and Infrastructure

Common Issues

Blog

Categories

Privacy Policy

Legal Notice

Use Model With Domain: An Interview on Domain Storytelling¶

Golo: Henning, Stefan, you are both working at WPS – Workplace Solutions and you are the creators of Domain Storytelling, a collaborative modeling technique that has gained a lot of attention in the Domain-Driven Design community. Before we dive into the method itself, can you tell us a bit about your backgrounds and how Domain Storytelling came to life?

Stefan: The predecessor of Domain Storytelling had been developed at the University of Hamburg and WPS, a university spin-off. When I joined WPS in 2005, my colleagues had been using the method in requirements workshops with clients. It went without saying that the diagrams were the backbone of our requirements and domain models. Since this was my first job as a professional software developer, it took me some time to realize that this was something special. It seemed like no one else on the planet worked like we did – until DDD started to gain adoption around 2015.

Henning: And that's when Domain Storytelling came to life. We simplified the academic method, gave it a catchy name and started talking about it at meetups and smaller conferences. 2018 was our break-out year with talks and workshops at all DDD conferences and the release of our open-source modeling tool Egon.io .

The Origins of Domain Storytelling¶

Golo: Domain Storytelling has a very distinctive visual language – pictographic icons, arrows, and numbered sentences that read almost like a storyboard. It reminds me of the classic LucasArts point-and-click adventures like Monkey Island or Indiana Jones and the Fate of Atlantis, where every interaction was built around actors, objects, and activities. Was there any such inspiration behind the visual style, or how did you arrive at this particular notation?

Stefan: The pictographic language was already part of Domain Storytelling's academic predecessor. It was inspired by Rich Pictures .

Henning: We strengthened the "storytelling" aspect: To us, the notation is not just icons and arrows – it consists of sentences with a subject, verb, and objects. The basic structure is who (an actor) does what (activity) with what (work object) with whom (another actor). A story consists of several sentences that are ordered by sequence numbers.

Golo: For those who haven't used Domain Storytelling yet – can you walk us through the basic mechanics? What does a typical Domain Storytelling workshop look like?

Henning: The workshop brings people together: people with questions (like developers and business analysts) and people with domain knowledge – our storytellers. They learn from each other in a structured conversation, led by a moderator. The moderator visualizes the conversation as a diagram – live, while the conversation takes place.

Stefan: The storytellers tell one scenario at a time. A scenario is a concrete, meaningful example of a business process. Usually very few domain stories are enough to grasp a business process.

In Practice¶

Golo: Many people in the DDD community are familiar with Event Storming as a collaborative modeling technique. How does Domain Storytelling differ from Event Storming, and when would you recommend one over the other? Or do they complement each other?

Stefan: People are surprised when I tell them that I use Event Storming almost as often as Domain Storytelling. In some cases, it does not even matter which modeling technique is used as long as it facilitates the conversation and a shared visualization is created. Yet, we recommend Domain Storytelling over Event Storming if the domain involves many actors (people or software) and you want to investigate how these actors cooperate with each other. Also, in my experience it is easier to design to-be processes with Domain Storytelling because a common perspective emerges more easily from a moderated, sentence-by-sentence approach.

Henning: If you know Event Storming, the first difference that you will notice is the layout of the model. Domain stories do not follow a left-to-right timeline, because they need to show cooperation between actors. That works better with arrows. Another difference is that each domain story is about one scenario.

Stefan: The workshop is also different. In Domain Storytelling, iterations of storming (discussing the next sentence) and consolidation (recording that sentence) are much smaller.

Golo: Can you walk us through a concrete example of how Domain Storytelling played out in a real project? What was the domain, what did the workshop look like, and what insights...