Warum eine gemeinsame Fachsprache so viel bewirkt
In klassischen Projekten gibt es mindestens zwei Sprachen: die Sprache des Fachbereichs und die Sprache der Entwickler. Dazwischen sitzen Übersetzer, etwa Business-Analysten, Product Owner oder ein Lastenheft. Jede Übersetzung kostet Präzision. Die Ubiquitous Language reduziert diese Übersetzungsschritte, weil alle Beteiligten dieselben Wörter mit derselben Bedeutung verwenden.
Übersetzungsverluste vermeiden
Ein Fachexperte spricht von einer „Teillieferung", das Ticket nennt es „Partial Shipment", die Datenbank hat eine Spalte split_flag und der Test prüft status == 7. Vier Begriffe für dieselbe Sache. Jeder Wechsel ist eine Gelegenheit für Fehler. Wenn stattdessen überall „Teillieferung" steht, kann ein Fachexperte einen Testnamen lesen und sofort sagen, ob die Regel stimmt.
Fachwissen im System sichern
Viele mittelständische Unternehmen hängen an wenigen Wissensträgern, die Sonderfälle und Ausnahmen im Kopf haben. Steht dieses Wissen in sprechend benannten Klassen, Methoden und Tests, überlebt es Personalwechsel. Gerade bei gewachsener Legacy-Software zeigt sich der Unterschied: Code mit Fachbegriffen lässt sich nachvollziehen, Code voller technischer Abkürzungen muss man mühsam rekonstruieren.
Dazu kommt ein Frühwarneffekt. Wenn ein Begriff im Gespräch sperrig wirkt oder Fachexperten ihn ständig umschreiben müssen, ist das oft ein Hinweis auf ein schwaches Modell. Die Sprache macht Designprobleme hörbar, bevor sie im Code teuer werden.
Gültigkeitsbereich: eine Sprache pro Bounded Context
Ein häufiges Missverständnis lautet, die Ubiquitous Language gelte für das ganze Unternehmen. Evans begrenzt sie bewusst auf einen Bounded Context, also einen klar abgegrenzten Bereich, in dem ein Modell und seine Begriffe eindeutig gelten. Martin Fowler beschreibt im Eintrag zum Bounded Context, warum ein einziges, unternehmensweites Modell in großen Domänen selten funktioniert.
Das Wort „Auftrag" zeigt es gut. Im Vertrieb ist ein Auftrag ein angenommenes Angebot mit Preis und Liefertermin. In der Fertigung ist es ein Fertigungsauftrag mit Arbeitsplan und Kapazitäten. Im Service ist es ein Einsatz beim Kunden. Alle drei Bedeutungen sind korrekt, aber eben nur in ihrem Kontext. Wer sie in ein gemeinsames Modell zwingt, erhält ein Objekt mit Dutzenden optionaler Felder, das niemand mehr versteht.
Die Grenzen zwischen den Kontexten und die Übersetzung an diesen Grenzen dokumentiert eine Context Map. Dort wird festgelegt, wie ein Vertriebsauftrag zum Fertigungsauftrag wird. Innerhalb eines Kontexts bleibt die Sprache dagegen strikt eindeutig.
So baust du eine Ubiquitous Language auf und hältst sie lebendig
Eine Fachsprache entsteht nicht in einem Meeting, sie wächst mit dem Projekt. Bewährt haben sich diese Schritte:
- Gemeinsam modellieren: Workshops wie Event Storming bringen Fachexperten und Entwickler an eine Wand. Alberto Brandolini hat das Format entwickelt, Details finden sich auf eventstorming.com. Die dort gesammelten Domänenereignisse wie „Wartung abgeschlossen" liefern die ersten Begriffe.
- Glossar pro Kontext anlegen: Jeder Begriff bekommt eine kurze Definition, ein Beispiel und gegebenenfalls verbotene Synonyme. Das Glossar liegt am besten versioniert im Repository, nah am Code.
- Begriffe überall verwenden: Klassen, Methoden, Events, Testnamen, API-Felder, Tickets und User Stories tragen dieselben Wörter. Code-Reviews prüfen auch die Benennung.
- Fachexperten einbinden: Sie lesen Testszenarien und Glossareinträge und widersprechen, wenn ein Begriff nicht passt.
- Abweichungen sofort klären: Taucht ein neues Synonym auf, entscheidet das Team, welcher Begriff gilt, und passt Glossar und Code an.
Begriffe ändern sich: Umbenennen gehört zur Arbeit
Eine Ubiquitous Language ist nie fertig. Neue Erkenntnisse führen zu neuen oder präziseren Begriffen. Stellt das Team fest, dass ein „Wartungsauftrag" eigentlich zwei verschiedene Dinge meint, etwa geplante Inspektion und Störungsbehebung, muss das Modell geteilt und der Code umbenannt werden. Dieses gezielte Refactoring ist kein Zusatzaufwand, es hält Sprache und Code synchron.
Moderne IDEs machen Umbenennungen im Code einfach. Schwieriger sind öffentliche Schnittstellen, Datenbankspalten und Events, die andere Systeme konsumieren. Hier helfen Versionierung, Übergangsphasen mit Alias-Feldern und eine klare Kommunikation an die abhängigen Teams.
Deutsch oder Englisch im Code? Zwei Positionen
In deutschen Unternehmen stellt sich eine Frage, die Evans' Buch kaum behandelt: In welcher Sprache stehen die Fachbegriffe im Code? Für beide Antworten gibt es gute Argumente, und die Entscheidung hängt vom Team und vom Umfeld ab.
Position 1: Deutsche Fachbegriffe im Code
Befürworter argumentieren, dass Begriffe wie „Rüstzeit", „Abnahme", „Gewährleistung" oder „Kommission" keine exakte englische Entsprechung haben. Jede Übersetzung erzeugt genau die Lücke, die die Ubiquitous Language schließen soll. Fachexperten können Testnamen direkt lesen, und das Glossar braucht keine Übersetzungsspalte. Der Nachteil: Mischcode wie getRuestzeit(), Umlaute in Bezeichnern, die je nach Tooling Probleme machen, und eine höhere Einstiegshürde für internationale oder externe Entwickler.
Position 2: Englisch durchgängig
Andere Teams schreiben konsequent Englisch, weil Frameworks, Bibliotheken und Fachliteratur englisch sind und weil internationale Kollegen ohne Deutschkenntnisse mitarbeiten. Der Code liest sich einheitlich. Der Preis ist eine Übersetzungsebene: Das Glossar muss jeden deutschen Fachbegriff verbindlich auf genau einen englischen Begriff abbilden, sonst entstehen konkurrierende Übersetzungen. Fehlübersetzungen fallen Fachexperten zudem kaum auf, weil sie den Code nicht lesen.
Viele Teams wählen einen Mittelweg: technisches Vokabular wie Repository, save oder Handler auf Englisch, Fachbegriffe auf Deutsch. Entscheidende Kriterien sind die Zusammensetzung des Teams, die Frage, ob Fachexperten Tests lesen sollen, und wie gut sich die Domänenbegriffe übersetzen lassen. Wichtig ist nur, dass die Entscheidung bewusst getroffen und im Glossar festgehalten wird.
BDD und Gherkin: die Sprache ausführbar machen
Behaviour-Driven Development (BDD) ist ein praktisches Werkzeug, um die Ubiquitous Language in Tests zu verankern. Dan North stellte BDD 2006 im Artikel „Introducing BDD" vor. Laut der Cucumber-Dokumentation wurde das Given/When/Then-Schema ausdrücklich von der Ubiquitous Language aus Evans' Buch beeinflusst.
Die Beschreibungssprache Gherkin ist laut Gherkin-Referenz von Cucumber in über 70 Sprachen verfügbar. Mit der Kopfzeile # language: de lauten die Schlüsselwörter unter anderem „Funktionalität", „Szenario", „Angenommen", „Wenn" und „Dann". So entstehen Akzeptanzkriterien, die Fachexperten lesen und Entwickler automatisiert ausführen:
# language: de
Funktionalität: Serviceeinsatz abschließen
Szenario: Abschluss ohne unterschriebenes Abnahmeprotokoll
Angenommen ein Serviceeinsatz ist im Status "laufend"
Wenn der Techniker den Einsatz ohne Kundenunterschrift abschließen will
Dann wird der Abschluss abgelehnt
Der Mehrwert liegt in der Sprache, nicht im Tool. Wenn die Szenarien andere Wörter benutzen als der Code, hat BDD seinen Zweck verfehlt.
Beispiel: Fachsprache im Code bei einem Maschinenbauer
Das folgende Beispiel ist fiktiv. Ein Maschinenbauer entwickelt eine Software für seinen technischen Kundendienst. Im Service-Kontext haben Fachbereich und Entwicklung diese Begriffe festgelegt:
Der Unterschied wird im Code sichtbar. Die erste Funktion ist technisch korrekt, verrät aber nichts über die Fachregel. Die zweite Variante benennt die Absicht und macht die Regel aus dem Gherkin-Szenario direkt lesbar:
// Unklar: technische Namen, die Fachregel steckt in Magic Numbers
function update(o: Order, s: number): void {
if (s === 4 && o.doc) {
o.status = s;
}
}
// Fachsprache: der Code sagt, was im Kundendienst passiert
type EinsatzStatus = "geplant" | "laufend" | "abgeschlossen";
class Serviceeinsatz {
private status: EinsatzStatus = "geplant";
abschliessen(protokoll: Abnahmeprotokoll): WartungAbgeschlossen {
if (!protokoll.istVomKundenUnterschrieben()) {
throw new AbnahmeFehlt(this.id);
}
this.status = "abgeschlossen";
return new WartungAbgeschlossen(this.id, protokoll.datum);
}
}
Dasselbe Prinzip funktioniert mit englischen Namen wie ServiceCall.complete(), solange das Glossar die Zuordnung verbindlich festlegt. Entscheidend sind sprechende Namen, die eine Fachhandlung ausdrücken, statt generischer Verben wie update oder process.
Typische Fehler bei der Ubiquitous Language
- Glossar ohne Codebezug: Ein Wiki-Glossar, das niemand pflegt und das im Code nicht auftaucht, bleibt Dekoration.
- Eine Sprache für das ganze Unternehmen: Wer „Kunde" oder „Auftrag" unternehmensweit vereinheitlichen will, erzeugt aufgeblähte Modelle. Jeder Bounded Context braucht seine eigene Sprache.
- Entwicklerjargon als Fachsprache: Begriffe wie „Entity", „DTO" oder „Flag" gehören nicht in die Gespräche mit dem Fachbereich.
- Synonyme dulden: Wenn „Einsatz", „Auftrag" und „Termin" dasselbe meinen sollen, muss das Team sich auf einen Begriff festlegen.
- Fachexperten außen vor lassen: Eine Sprache, die nur Entwickler definieren, ist keine gemeinsame Sprache.
- Umbenennen scheuen: Veraltete Namen im Code, weil das Umbenennen lästig erscheint, lassen Sprache und Modell auseinanderdriften.
Häufige Fragen zu Ubiquitous Language
Was ist der Unterschied zwischen Ubiquitous Language und einem Glossar?
Ein Glossar ist ein Dokument. Die Ubiquitous Language ist die gelebte Sprache des Teams, die in Gesprächen, Tickets, Tests und Code gleichermaßen verwendet wird. Das Glossar ist ein Hilfsmittel, um diese Sprache festzuhalten. Ohne Verwendung im Code bleibt es wirkungslos.
Brauche ich Domain-Driven Design, um eine Ubiquitous Language zu nutzen?
Nein. Der Begriff stammt aus DDD, aber jedes Softwareprojekt profitiert davon, wenn Fachbereich und Entwicklung dieselben Begriffe verwenden. Ihre volle Wirkung entfaltet die Sprache allerdings zusammen mit einem bewusst gestalteten Domänenmodell und klaren Bounded Contexts.
Wer ist für die Ubiquitous Language verantwortlich?
Das gesamte Team, bestehend aus Fachexperten und Entwicklern. In der Praxis hilft es, wenn eine Person, etwa der Product Owner, Änderungen am Glossar koordiniert. Entscheidungen über Begriffe trifft das Team aber gemeinsam, und Code-Reviews achten auf die Einhaltung.
Wie fange ich in einem bestehenden System an?
Beginne mit dem Kontext, an dem gerade aktiv entwickelt wird. Sammle in einem Workshop die wichtigsten Begriffe, lege ein kleines Glossar an und benenne neuen Code konsequent danach. Bestehenden Code passt du schrittweise an, sobald du ihn ohnehin anfasst.
