Domain Storytelling: Warum Ihre Dokumentation niemand lesen will (und was Sie dagegen tun können)

Mal ehrlich: Wie viele technische Dokumentationen haben Sie schon gelesen und dachten sich dabei "Hier könnte ich auch einfach pennen"? Genau. Wir kennen das alle.

Dabei ist die Grundidee von technischer Dokumentation eigentlich simpel: Erzähle anderen Menschen, warum ein System existiert und wie es funktioniert. Nur leider scheitern die meisten Ansätze genau daran.

Was zum Teufel ist Domain Storytelling?

Domain Storytelling ist ein kollaborativer Ansatz, bei dem Entwicklungsteams, Fachbereichsexperten und Stakeholder gemeinsam herausarbeiten, wie ein System funktioniert – und zwar durch Geschichten.

Ja, richtig gelesen: Geschichten.

Statt ellenlanger UML-Diagramme oder seitenlanger Spezifikationsdokumente, die im Nirgendwo verstauben, erstellt ihr visuelle Erzählungen. Ihr zeigt, wer was macht, wann und warum. Jeder kann das verstehen – nicht nur Entwickler.

Im Kern identifiziert ihr drei Dinge: Die Akteure (also Menschen und Systeme, die beteiligt sind), ihre Aktivitäten (was sie konkret tun) und die Arbeitsobjekte (also die Dinge, die erstellt, verändert oder verwendet werden). Diese Elemente verwebt ihr zu einer visuellen Sequenz, die sich liest wie ein Ausschnitt aus dem Arbeitsalltag.

Warum sollte sich das für Entwickler lohnen?

Hier wird es spannend: Das meiste technische Schulden entstehen nicht durch schlechten Code. Sie entstehen durch Missverständnisse.

Ihr baut das, was ihr denkt, dass der Stakeholder wollte. Der Stakeholder wollte aber etwas völlig anderes. Und zack – sitzt ihr um 2 Uhr morgens beim Refactoring.

Domain Storytelling deckt solche Missverständnisse frühzeitig auf. Wenn ihr den Geschäftsprozess plötzlich visualisiert vor euch seht, fallen Lücken, Redundanzen und Fehlannahmen sofort auf.

Für eventgetriebene Systeme ist das besonders wichtig – und hier kommt EventSourcingDB ins Spiel. Eine Event-Sourced-Architektur lebt und stirbt damit, wie gut sie reales Domänenverhalten abbildet. Stimmt die Geschichte nicht, werdet ihr Monate damit verbringen, nachträglich euer Event-Schema anzupassen.

Die handfesten Vorteile

Schnelleres Onboarding: Neue Teammitglieder verstehen den Systemzweck in Minuten statt Tagen.

Weniger Nacharbeit: Alle sind sich über das "Was" einig, bevor auch nur eine Zeile Code geschrieben wird.

Bessere Kommunikation mit Stakeholdern: Nicht-technische Partner können wirklich sinnvoll an Planungsgesprächen mitwirken.

Klarere Event-Modellierung: Wer mit Event Sourcing arbeitet, dem werden Aggregate-Grenzen und Event-Beziehungen durch die visuelle Darstellung intuitiv klar.

Wie fängt man an?

Ihr braucht keine teuren Tools. Ein Whiteboard, ein paar Post-its und die Bereitschaft, Fachbereichsexperten zuzuhören, reichen völlig aus.

Der Kern des Ganzen ist einfach: Fragt immer wieder "Was passiert als nächstes?" – bis ihr den gesamten Geschäftsprozess abgebildet habt. Achtet besonders auf Momente, in denen Leute zögern, widersprechen oder sagen "Naja, so einfach ist es dann doch nicht". Genau dort versteckt sich die echte Komplexität eurer Domäne.

Zurück zum Technik-Stack

Ob ihr eine einfache Landingpage baut oder ein komplexes verteiltes System auf eurem Cloud-Hosting betreibt – das Prinzip gilt immer: Versteht ihr die menschliche Geschichte hinter eurer technischen Lösung, führt das zu besseren Ergebnissen.

Euer Domain-Modell ist nur so gut wie euer Verständnis der Domäne selbst. Domain Storytelling bietet euch einen strukturierten, wiederholbaren Weg, dieses Verständnis gemeinsam aufzubauen.

Wenn ihr das nächste Mal ein neues Feature oder System plant, lasst das endlos lange Anforderungsdokument weg. Schnappt euch einen Marker. Erzählt erst die Geschichte.

Habt ihr Domain Storytelling schon in euren Projekten ausprobiert? Teilt eure Erfahrungen in den Kommentaren – wir wollen wissen, was funktioniert hat (und was eher nicht).