Ubiquitous Language ist kein DDD-Deko-Begriff

Ubiquitous Language klingt erstmal nach einem dieser Begriffe, die man in DDD-Vorträgen braucht, damit die Folien nach Architektur aussehen.

Ist es aber nicht.

Ubiquitous Language ist einer der wichtigsten Schutzmechanismen in Softwareprojekten. Gegen Missverständnisse. Gegen falsche Modelle. Gegen kaputte APIs. Gegen UI-Texte, die etwas anderes versprechen als der Code tut. Und gegen Bugs, die eigentlich gar keine technischen Bugs sind, sondern sprachliche Unfälle mit Deployment-Pipeline.

Die Idee ist einfach:

Ein Team braucht eine gemeinsame Sprache für die Fachlichkeit, an der es arbeitet.

Nicht irgendeine Projektsprache. Nicht ein paar Begriffe im Wiki. Nicht „Business nennt es so, IT nennt es anders, aber wir wissen schon, was gemeint ist“.

Sondern eine Sprache, die Fachbereich, Produkt, Entwicklung, Test, UI, API und Code bewusst miteinander verbindet.

Das ist Ubiquitous Language.

Warum Sprache im DDD so zentral ist

Domain-driven Design dreht sich nicht zuerst um Pattern.

Nicht um Aggregates. Nicht um Repositories. Nicht um Value Objects. Nicht um irgendwelche taktischen Bausteine, die man in ein Projekt wirft, damit es erwachsener aussieht.

DDD beginnt mit der Domäne.

Also mit dem Problemraum. Mit der Fachlichkeit. Mit den Regeln, Begriffen, Abläufen, Ausnahmen und Bedeutungen, die ein System abbilden soll.

Und genau dort wird Sprache entscheidend.

Denn wie willst du ein gutes Fachmodell bauen, wenn nicht einmal klar ist, wie die Fachbegriffe heißen? Wie willst du Grenzen schneiden, wenn ein Begriff in drei Teams unterschiedliche Dinge bedeutet? Wie willst du APIs stabil halten, wenn niemand sauber sagen kann, was ein Objekt fachlich repräsentiert?

Ein Modell entsteht nicht erst im Code. Ein Modell entsteht in Sprache.

Code ist später nur die sehr präzise, sehr nachtragende Form davon.

Wenn die Sprache unscharf ist, wird das Modell unscharf. Wenn das Modell unscharf ist, wird der Code es irgendwann brutal ehrlich machen.

Ubiquitous heißt nicht: alle Wörter immer gleich

Ein Missverständnis vorweg: Ubiquitous Language bedeutet nicht, dass überall exakt dieselben Wörter stehen müssen.

Ein UI-Label darf nutzerfreundlicher sein als ein interner Fachbegriff. Ein API-Feld darf technischer heißen als ein Button. Ein Datenmodell hat andere Zwänge als eine Oberfläche. Und Alltagssprache im Team ist manchmal kürzer als ein sauberer Domänenbegriff.

Das ist nicht automatisch falsch.

Falsch wird es, wenn diese Unterschiede zufällig entstehen.

Wenn der Kunde einen Begriff benutzt, der Product Owner einen zweiten, das Backend einen dritten, das Frontend einen vierten und die Datenbank einen fünften — und alle so tun, als wäre das nur Geschmackssache.

Ist es nicht.

Dann ist nicht mehr klar, ob verschiedene Namen dasselbe Konzept meinen. Oder ob derselbe Name verschiedene Konzepte meint. Beides ist gefährlich.

Ubiquitous Language bedeutet deshalb nicht sprachliche Gleichschaltung. Es bedeutet bewusste Abbildung.

Es muss klar sein:

• Was ist der fachliche Begriff?
• Wie wird er in der UI gezeigt?
• Wie heißt er im API-Vertrag?
• Wie heißt er im Code?
• In welchem Kontext gilt diese Bedeutung?
• Wo wird übersetzt?
• Und wo darf auf keinen Fall stillschweigend übersetzt werden?

Wenn diese Zuordnung nicht klar ist, entsteht kein flexibles System. Es entsteht semantischer Nebel mit Autocomplete.

Die Sache mit dem Statement

Ich wurde einmal in eine Bugdiskussion geholt.

Im Call waren ein Frontend-Entwickler, ein Backend-Entwickler, ein externer Kunde, interne Stakeholder, ein Product Owner und irgendwann ich als Architekt. Das Meeting hatte alles: einen Bug, sechs Meinungen und ein Objekt namens Statement.

Alle sprachen über dieses Statement.

Leider meinte niemand exakt dasselbe.

Der Kunde sprach fachlich von einer Leistungsabrechnung. In der IT wurde daraus irgendwann ein Accounting Statement. Weil Menschen gerne Zeit sparen, wurde daraus im Alltag nur noch Statement.

Parallel hatte das Frontend an anderer Stelle eine tatsächliche Rechnung modelliert. Also etwas, das fachlich eher eine Invoice war. Das Objekt hieß aber ebenfalls statement.

Vermutlich, weil es ähnlich aussah. Oder weil es schon irgendwo ein statement gab. Oder weil „das historisch so gewachsen ist“. Einer dieser Sätze, bei denen man weiß: Hier liegt irgendwo ein alter Architekturunfall unter Laminat.

Das Ergebnis:

Der Kunde meinte eine Leistungsabrechnung. Das Backend meinte ein Accounting Statement. Das Frontend meinte eine Rechnung. Der PO dachte an einen Prozesszustand. Stakeholder dachten teilweise an einen Bericht.

Alle redeten über dasselbe Wort. Leider nicht über dasselbe Ding.

Und genau das ist der Punkt.

Das Problem war nicht, dass Statement ein englischer Name war. Englisch ist nicht böse. Deutsch rettet auch keine Architektur. Das Problem war, dass das Wort kein klares fachliches Konzept mehr repräsentierte.

Es war ein Container für mehrere Bedeutungen geworden.

Wenn ein Begriff alles bedeuten kann, kann er im Code nichts mehr zuverlässig bedeuten.

Das war kein Naming-Problem

Man könnte jetzt sagen: „Okay, dann benennt man das halt sauber um.“

Ja. Auch.

Aber das greift zu kurz.

Ein falscher Name ist oft nur das sichtbare Symptom eines tieferen Problems. Nämlich, dass das Team kein gemeinsames fachliches Modell hat.

Ein Name ist nicht nur Kosmetik. Ein Name transportiert Annahmen.

Wenn ein Objekt Invoice heißt, erwarte ich eine Rechnung. Wenn es Statement heißt, erwarte ich irgendeine Art Auszug, Erklärung oder Abrechnung. Wenn es BillingReport heißt, erwarte ich einen Bericht. Wenn es Settlement heißt, erwarte ich einen Ausgleich oder eine Abwicklung.

Diese Erwartungen beeinflussen, wie Entwickler Code schreiben. Wie Tester Testfälle formulieren. Wie Product Owner Akzeptanzkriterien beschreiben. Wie Stakeholder Anforderungen verstehen. Wie Nutzer die Oberfläche interpretieren.

Namen sind Architektur.

Nicht, weil schöne Namen elegant aussehen. Sondern weil Namen Grenzen ziehen. Verantwortung ausdrücken. Bedeutungen stabilisieren. Oder eben verwischen.

Mundfaulheit ist kein Architekturprinzip.

Warum das im Frontend besonders weh tut

Im Frontend wird kaputte Sprache schnell sichtbar.

Das Frontend liegt genau zwischen Nutzer, Produkt, Design, Backend und API. Es muss Fachlichkeit darstellen, Eingaben führen, Zustände erklären, Fehler übersetzen und oft mehrere technische Modelle in ein verständliches ViewModel bringen.

Wenn die Fachsprache unklar ist, wird das Frontend zum Übersetzungsbüro für Modellierungsversäumnisse.

Dann heißt das API-Feld statement, die UI zeigt „Rechnung“, der Fachbereich sagt „Leistungsabrechnung“, im Formular steht „Abrechnungsnachweis“ und im Code gibt es ein StatementViewModel, das je nach Route etwas anderes bedeutet.

Das kann man technisch alles bauen.

Man kann auch ein Haus mit feuchtem Keller tapezieren.

Die Frage ist nur, wie lange man so tun möchte, als wäre das Problem die Tapete.

Gerade Frontend-Architektur braucht deshalb eine saubere Sprache. Nicht, weil Frontend „Business-nah“ klingt, sondern weil es dort auffällt, wenn Produktmodell, Nutzerverständnis und technische Schnittstellen nicht zusammenpassen.

Bounded Contexts machen Unterschiede sichtbar

Natürlich darf ein Begriff in unterschiedlichen Kontexten unterschiedlich verwendet werden.

Ein Account im Identity-Kontext ist nicht zwingend dasselbe wie ein Account im Buchhaltungskontext. Ein Statement im Banking kann etwas anderes sein als ein Statement in einer Leistungsabrechnung. Ein Customer im CRM ist nicht automatisch dasselbe Modell wie ein Customer im Support oder in der Rechnungsstellung.

Das ist okay.

Aber dann muss die Grenze sichtbar sein.

Genau dafür sind Bounded Contexts so wichtig. Nicht als Architekturmodewort, sondern als Schutzzaun für Bedeutung.

Innerhalb eines Kontextes sollte ein Begriff präzise sein. Über Kontextgrenzen hinweg darf übersetzt werden. Aber diese Übersetzung muss bewusst passieren.

Nicht heimlich über ein DTO, das überall durchgereicht wird. Nicht über ein Shared Model, das angeblich neutral ist und in Wahrheit nur alle Unschärfen zentralisiert. Nicht über ein Objekt namens Statement, das alles meint, damit niemand entscheiden muss.

Wenn ein Begriff in verschiedenen Kontexten unterschiedliche Bedeutungen hat, dann ist das kein Problem. Wenn niemand weiß, in welchem Kontext er gerade spricht, dann schon.

Warnsignale für kaputte Sprache

Ein paar Sätze sollten in Projekten sofort Aufmerksamkeit erzeugen:

• „Das heißt bei uns historisch so.“
• „Der Kunde nennt es anders.“
• „Im Frontend heißt es anders als im Backend.“
• „Das ist eigentlich eine Rechnung, aber im Code heißt es Statement.“
• „Das ist schwer zu erklären, aber alle wissen, was gemeint ist.“
• „Das ist so ein Sammelobjekt.“
• „Das Feld wird je nach Fall unterschiedlich interpretiert.“
• „Technisch ist das dasselbe, fachlich aber nicht ganz.“
• „Wir übersetzen das später sauber.“
• „Alle wissen, was gemeint ist.“

Der letzte Satz ist besonders gefährlich.

„Alle wissen, was gemeint ist“ heißt oft nur: Alle haben gelernt, mit derselben Unschärfe zu leben.

Das ist kein gemeinsames Verständnis. Das ist kollektive Resignation mit Sprintziel.

Was man konkret tun kann

Ubiquitous Language muss nicht mit einem großen DDD-Workshop beginnen.

Oft reicht es, in den richtigen Momenten langsamer zu werden.

Gerade bei hitzigen Bugdiskussionen sollte man nicht sofort in Logs, JSON-Payloads oder Schuldfragen springen. Erst klären:

Reden wir gerade wirklich vom selben Ding?

Bei einem Objekt namens Statement wären gute Fragen gewesen:

Statement wovon? Für wen? In welchem Prozess? Welche fachliche Verantwortung hat dieses Objekt? Ist es eine Rechnung? Eine Leistungsabrechnung? Ein Bericht? Ein Status? Ein Dokument? Eine Buchungsinformation?

Wenn darauf mehrere verschiedene Antworten kommen, hat man etwas Wertvolles gefunden: nicht den Bug, sondern die Ursache für eine ganze Bug-Klasse.

Praktisch helfen ein paar einfache Regeln:

Begriffe pro Kontext definieren. Fachbegriffe nicht aus Bequemlichkeit verwässern. Code-Objekte nach fachlicher Verantwortung benennen. API-Verträge nicht mit schwammigen Sammelbegriffen füllen. Bei Übersetzungen prüfen, ob die Bedeutung erhalten bleibt. UI-Labels bewusst auf Fachbegriffe abbilden. Glossare leichtgewichtig halten, aber lebendig. Und wenn ein Begriff mehrere Bedeutungen hat: explizit modellieren statt weiter drum herumreden.

Das Ziel ist nicht Sprachpolizei.

Das Ziel ist, dass Fachlichkeit stabil genug wird, um daraus Software zu bauen.

Gemeinsame Sprache ist Architekturarbeit

Ubiquitous Language ist kein dekorativer DDD-Begriff.

Sie ist die Verbindung zwischen Fachlichkeit und Code. Zwischen Kunde und Team. Zwischen Produktentscheidung und Implementierung. Zwischen dem, was gemeint ist, und dem, was gebaut wird.

Wenn diese Verbindung bricht, entstehen keine kleinen Schönheitsfehler. Dann entstehen falsche Modelle, falsche APIs, falsche Oberflächen und Bugs, die niemand sofort versteht, weil alle mit denselben Wörtern unterschiedliche Bilder im Kopf haben.

Deshalb ist Sprache Architekturarbeit.

Nicht die hübsche Art von Architekturarbeit mit Diagrammen und Pfeilen. Eher die unangenehme Art, bei der man im Meeting fragt:

„Moment. Was genau meinen wir eigentlich mit Statement?“

Und plötzlich wird es still.

Das ist meistens ein gutes Zeichen.

Merksatz

Wenn alle dasselbe Wort benutzen, heißt das noch lange nicht, dass sie dasselbe Modell meinen.

Ubiquitous Language beginnt nicht im Glossar. Sie beginnt in dem Moment, in dem jemand fragt:

Reden wir gerade wirklich vom selben Ding?