Domain Storytelling ist eine Methode aus dem Bereich Collaborative Modeling, bei der Fachexperten und Entwickler gemeinsam Geschichten aus der Domäne erzählen und diese in einer einfachen grafischen Notation aufzeichnen. Akteure, Arbeitsgegenstände und Aktivitäten bilden das Bild. Ziel ist direkte Kommunikation statt stiller Post, um Missverständnisse zwischen Anwendern und Technik zu vermeiden.
Das Wichtigste in Kürze
- Domain Storytelling ersetzt das klassische Pflichtenheft-Modell durch direkte Konversation zwischen Anwendern und Entwicklern, weil jede Übersetzungsstufe dazwischen Information verliert.
- Eine Domain Story zeigt maximal 10 bis 20 Schritte und beschreibt immer nur ein einziges Szenario, sodass Fachleute ohne technische Vorbildung das Diagramm sofort lesen können.
- Aus feingranularen Domain Stories lassen sich direkt BDD-Testfälle ableiten, weil Akteur, Aktivität und Arbeitsgegenstand den Given-When-Then-Aufbau von Cucumber-Tests bereits vorgeben.
- Domain Storytelling ist kein Ersatz für UML oder BPMN, sondern ergänzt sie: UML kommuniziert zwischen Entwicklern, Domain Stories zwischen Entwicklern und Anwendern.
Was ist Domain Storytelling?
Domain Storytelling ist eine Methode, mit der Entwickler und Fachexperten gemeinsam verstehen, wie eine Fachdomäne wirklich funktioniert. Sie gehört in den Werkzeugkasten des Collaborative Modeling und kombiniert zwei Zutaten: ein Workshop-Format und eine grafische Notation.
Der Grundgedanke ist einfach. Anwender erzählen eine Geschichte aus ihrer Fachlichkeit, und während sie erzählen, zeichnet das Team diese Geschichte als Diagramm auf. Das Diagramm dient als Spiegel. Es zeigt sofort, ob das Gehörte richtig verstanden wurde.
Henning Schwentner ordnet die Methode klar agil ein. Es geht nicht um ein Pflichtenheft, das vorne entsteht und über den Zaun geworfen wird. Es geht um eine Konversation, die ein geschriebenes Dokument nicht ersetzen kann.
Warum reicht ein Anforderungsdokument nicht aus?
Geschriebene Anforderungen allein lassen zu viel Raum für Missverständnisse. Domain Storytelling setzt deshalb auf direkte Kommunikation zwischen Anwender und Entwickler, statt auf eine Kette von Übersetzungsschritten.
Das Problem dahinter ist der klassische Stille-Post-Effekt. Der Anwender erzählt es dem Business Analysten, der Business Analyst dem Architekten, der Architekt dem Entwickler. Bei jedem Schritt geht Information verloren. Am Ende entsteht etwas, das mit dem ursprünglichen Bedarf wenig zu tun hat.
Die Methode holt die Vermittlerrollen aus der Übersetzerfunktion heraus und bringt sie in eine Moderatorenrolle. Requirements Engineer, Business Analyst oder Architekt sorgen nicht mehr für die Übersetzung, sondern dafür, dass eine Konversation von Anfang bis Ende direkt stattfindet.
Wie eine Domain-Storytelling-Session abläuft
Eine Session beginnt typischerweise grobgranular und arbeitet sich dann ins Detail vor. Zuerst entsteht ein Big Picture, danach werden einzelne Teilprozesse feiner ausgeleuchtet.
Am Anfang lädt man viele Beteiligte ein, um die Domäne überhaupt zu erfassen. Für eine Bahnreise wären das etwa ein Reisender, ein Lokführer und ein Schaffner. Gemeinsam erzählen sie die große Geschichte von A bis Z, ohne sich in Details zu verlieren.
Aus diesem Big Picture lassen sich Grenzen ziehen, in Richtung Subdomänen und Bounded Contexts. Innerhalb eines einzelnen Bounded Context geht man dann tiefer, mit feingranularen Stories. Ticket kaufen und Ticket kontrollieren sind dabei getrennte Geschichten mit unterschiedlichen Akteuren.
Die feineren Stories macht man mit kleineren Gruppen. Wie eine Ticketkontrolle abläuft, betrifft den Reisenden und den Schaffner, nicht den Kartenverkäufer. Wer kein Detailwissen zu einem Schritt hat, braucht auch nicht im Raum zu sein.
So sieht die grafische Notation aus
Die Notation arbeitet mit Strichmännchen, Icons und Pfeilen und übersetzt jeden gesprochenen Satz in ein Bild. Sie heißt pictographic language, eine Bildersprache, die bewusst leichtgewichtig bleibt.
Ein Beispiel: “Der Schaffner kontrolliert das Ticket vom Reisenden.” Daraus werden zwei Strichmännchen, Schaffner und Reisender, ein Work Object für den Arbeitsgegenstand Ticket und eine Aktivität, die an einen Pfeil geschrieben wird. Akteur, Aktivität, Arbeitsgegenstand, in dieser Reihenfolge.
Texte gehören dazu, aber sparsam. Namen für Akteure, Rollen und Arbeitsgegenstände, vor allem aber die fachlichen Verben. Genau diese Verben helfen, die Fachsprache zu lernen und daraus die Ubiquitous Language zu formen, wie sie im Domain-Driven Design genannt wird. Annotationen fangen alles auf, was die grafische Notation nicht abbildet.
Eine Story, ein Szenario
Domain Storytelling folgt dem Prinzip des Szenario-based Modeling: Eine Domain Story erzählt genau ein Szenario, nicht alle Varianten in einem Bild. Das ist der zentrale Unterschied zu vielen anderen Notationen.
Als Faustregel umfasst eine Story etwa 10 bis 20 Schritte. Wird es feiner, wandert der Detailprozess in eine eigene Story. Eine typische Session produziert deshalb nicht eine Story, sondern viele.
Man beginnt mit dem Happy Path. Erst danach kommen die Sonderfälle: Der Reisende hat nicht genug Geld. Der Reisende verpasst den Anschluss. Jeder dieser Fälle bekommt ein eigenes Bild. Der Grund ist pragmatisch. Endanwender sind nicht mit Conditionals aufgewachsen, getrennte Bilder bleiben für sie verständlich.
Domain Storytelling und UML lösen verschiedene Probleme
UML ist ein Medium für die Kommunikation zwischen Entwicklern, Domain Storytelling eines für die Kommunikation zwischen Entwickler und Anwender. Genau hier liegt der Unterschied.
UML ist mächtig, aber nicht einfach. Wer es vollständig verstehen will, muss viel lernen. Für den nicht technischen Anwender ist das ungeeignet. Die Bildersprache von Domain Storytelling lässt sich dagegen in fünf Minuten erklären, danach kann der Workshop starten.
Beide Ansätze schließen sich nicht aus. Aus einer Domain Story lässt sich im Anschluss ein UML-Klassendiagramm ableiten, und Use-Case-Diagramme helfen, mehrere Domain Stories als Überblick zusammenzuführen. Ähnliches gilt für BPMN, das ebenfalls für technische Leser gedacht ist und mehrere Fälle in ein Diagramm packt.
Wie aus Domain Stories Tests und Code entstehen
Domain Stories der richtigen Granularität lassen sich fast eins zu eins in Akzeptanztests übersetzen. Die Methode passt damit gut zu Test Driven Development und Behavior Driven Development.
Aus einer Story leitet sich ein erster Testfall ab, etwa in Cucumber oder JUnit. Die verschiedenen Varianten einer Domäne ergeben weitere Testfälle. Das Given und When eines BDD-Tests lässt sich direkt aus der Story herauslesen, wenn die Granularität stimmt.
Die Reihenfolge ist klar: Die Domain Story erklärt den Test, der Test schneidet den Produktivcode. Im Buch zu Domain Storytelling zeigt ein Kapitel namens “Modeling in Code”, wie man die passende Granularität findet, BDD-Testcases ableitet und sowohl objektorientiert als auch funktional implementiert.
Welche Werkzeuge brauchst du für einen Workshop?
Du brauchst kein spezielles Tool, aber es gibt eines. Egon.io läuft im Browser und unterstützt die Methode vollständig, sodass sich ein Modell mit Maus und Tastatur erzeugen lässt.
Genauso gut funktioniert ein Whiteboard. Es ist meist besser als ein Flipchart, weil sich Inhalte wegwischen lassen. Eine bewährte Kombination: Work Objects und Akteure auf Klebezetteln, die sich verschieben lassen, Pfeile auf dem Whiteboard, die man neu malen kann. Das Haptische hilft, weil sich ein Sticky Note hin und her schieben lässt.
Auch online klappt das, wie sich während der Corona-Zeit gezeigt hat. Voraussetzung ist ein guter Videocall, in dem alle ihr Video anhaben, denn Körpersprache und visuelles Feedback spielen eine Rolle. Ein virtuelles Whiteboard wie Miro ermöglicht die gemeinsame Arbeit.
Domain Storytelling ist ein Werkzeug, kein goldener Hammer
Domain Storytelling ist eine Methode unter mehreren, nicht die Lösung für jeden Fall. Wer sie auf alles anwendet, fällt dem Golden-Hammer-Syndrom zur Beute.
Bei einem Nagel ist das eine gute Idee, bei einer Schraube nicht mehr so eine gute Idee und bei einer Wasserleitung vielleicht sogar eine schlechte. So ist das mit Modellierungswerkzeugen auch. — Henning Schwentner
Sinnvoller ist es, sich eine Werkzeugkiste aufzubauen: mit einem Werkzeug anfangen, Erfahrung sammeln und dann in die Breite gehen. Verwandte Techniken im Collaborative Modeling sind Event Storming, User Story Mapping und, im BDD-Umfeld, Example Mapping.
Domain Storytelling spielt seine Stärke aus, wenn Menschen miteinander interagieren und kooperieren. Solche Kooperationen werden in den Bildern gut sichtbar. In anderen Arten von Domänen darf man es ausprobieren und ehrlich prüfen: Bekommst du einen Griff an die Domäne oder nicht? Funktioniert es nicht, ist das der Moment, ein anderes Werkzeug aus der Kiste zu holen, statt sich in die Methode zu verlieben und sie tot zu reiten.
