Ubiquitous Language: ein gemeinsames Vokabular als Fundament

Teil 5 der Reihe "Software gemeinsam gestalten". Zur Übersicht

Sprache ist das wichtigste Werkzeug in einem Softwareprojekt. Jedes Gespräch zwischen Fachleuten und Entwickler:innen, jede Anforderung, jede Bezeichnung in der Anwendung transportiert ein Verständnis davon, was die Software tun soll. Wenn dieses Verständnis auseinanderläuft, weil zwei Seiten verschiedene Wörter für dasselbe benutzen oder dasselbe Wort für Verschiedenes, entstehen Fehler, die kein Test fängt.

Was Ubiquitous Language bedeutet

Eric Evans hat den Begriff in "Domain-Driven Design" geprägt: eine gemeinsame Sprache, die Fachleute und Entwickler:innen gleichermaßen verwenden, im Gespräch, in der Dokumentation und im Code. Sie lebt in jeder Unterhaltung und entwickelt sich mit dem Verständnis der Fachdomäne weiter.

Die Ubiquitous Language gilt innerhalb eines Bounded Context. Verschiedene Kontexte dürfen verschiedene Begriffe für ähnliche Konzepte verwenden, weil sie unterschiedliche Perspektiven auf die Fachdomäne abbilden. Eine "Spende" im Fundraising meint die Beziehung zur Spender:in, in der Buchhaltung den Zahlungseingang mit Buchungssatz. Diese Unterscheidung ist gewollt und macht die Sprache präziser.

Wie Sprachbrüche entstehen

In den meisten Projekten gibt es drei Sprachen: die der Fachabteilung, die der Entwickler:innen und die des Codes. Die Fachabteilung spricht von "Freigabe", das Entwicklungsteam sagt "Approval", und in der Anwendung heißt der Knopf "Bestätigen". Jede Übersetzung ist eine Gelegenheit für ein Missverständnis. Über Monate summieren sich diese kleinen Abweichungen zu einem System, das technisch funktioniert, aber fachlich schwer zu durchschauen ist.

Ein häufiger Stolperstein sind Wörter, die gleich klingen, aber in verschiedenen Abteilungen Verschiedenes meinen. "Kunde" kann eine Privatperson sein, ein Unternehmen oder ein interner Auftraggeber. Ohne Klärung baut jemand die Software auf einer Annahme, die erst Monate später in einem Grenzfall auffällt.

Wie ihr eine gemeinsame Sprache aufbaut

1. 01

   Im Workshop starten

   Event Storming und ähnliche Formate bringen die Fachsprache auf den Tisch, weil alle Beteiligten Abläufe in ihren eigenen Worten beschreiben. Widersprüche werden sichtbar, bevor sie im Code landen.

2. 02

   Begriffe bewusst wählen

   Wenn ein Begriff mehrdeutig ist, einigt euch auf eine Definition pro Kontext. Schreibt sie auf, aber wichtiger: benutzt sie. Eine Sprache lebt im Gespräch.

3. 03

   Code an die Sprache anpassen

   Die Bausteine der Software tragen die Begriffe der Fachdomäne. Wenn die Anwendung "Spende" sagt und das Team "Spende" sagt, kann jede:r nachvollziehen, ob die Software das Richtige tut.

4. 04

   Sprache pflegen

   Wenn sich das Fachverständnis ändert, ändert sich der Code mit. Eine Umbenennung, die einen Fachbegriff aktualisiert, ist genauso wertvoll wie eine strukturelle Verbesserung.

Was eine gemeinsame Sprache bewirkt

Teams mit einer Ubiquitous Language sprechen effizienter. Anforderungen lassen sich direkt in die Software übersetzen, weil die Begriffe schon passen. Neue Teammitglieder finden sich schneller zurecht, weil der Code sich wie eine Beschreibung der Fachdomäne liest. Und Fehler fallen früher auf, weil Fachleute die Prüfung der Software inhaltlich begleiten können.

Code, der die Sprache des Teams spricht, lässt sich gemeinsam weiterentwickeln.

Rückblick auf die Reihe

Die gemeinsame Sprache ist das Bindeglied zwischen allem, was wir in den vorigen Teilen beschrieben haben: dem gemeinsamen Gestalten als Haltung, Domain-Driven Design als Denkrahmen, Event Storming als Workshop-Format und den Bounded Contexts als architektonischem Schnitt. Im nächsten und letzten Teil zeigen wir, wie diese Ideen konkret auf der Power Platform und in Dynamics 365 CE aussehen.