Software ArchitectureAtlas

Software Architecture Atlas

Überblick gewinnen. Zusammenhänge verstehen.

PrinzipKapitel I · Domäne · Baustein 2 von 7

Ubiquitous Language

Ubiquitous Language ist die gemeinsam gepflegte Sprache von Fachleuten und Entwicklung. Ihre Begriffe erscheinen konsistent in Gesprächen, Modellen, Tests und Code.

Von Michael Meierhoff · Meierhoff Systems

  1. Ein WortEin Begriff, ein Wort, überall gleich.
  2. Alle OrteGespräch, Ticket, Test und Code.
  3. Feste ZuordnungDeutscher Begriff entspricht einem englischen Bezeichner.

Einordnung

Warum das wichtig ist

Wenn Gespräch, Ticket, Test und Code dasselbe Wort nutzen, fallen Missverständnisse früh auf. Das Team legt einmal fest, wie deutsche Fachbegriffe zu englischen Bezeichnern passen, etwa Bestellung zu Order. Den Geltungsbereich einer Sprache behandelt der Baustein Bounded Context.

Dieser Baustein erklärt gemeinsame Fachbegriffe. Für den Geltungsbereich einer Sprache siehe Bounded Context.

Auf einen Blick · Eine Sprache an allen Orten

Fachleute und Entwicklung pflegen gemeinsam einen Wortschatz, der in Gespräch, Ticket, Test und Code gleich lautet.
Shop-Beispiel · Begriffsspur

Ein Begriff, vier Orte

Das Shop-Team klärt die Wörter Bestellung, Reservierung, Autorisierung und Rechnung. Jeder Begriff erhält eine prüfbare Bedeutung im passenden Kontext.

So liest du das Bild

  1. Ein Wort Im gemeinsamen Zustand steht je Begriff dasselbe Wort an allen vier Orten.
  2. Alle Orte Die vier Karten; rot markiert, wo ein Ort abweicht, etwa Rechnung statt Bestellbestätigung.
  3. Feste Zuordnung Auf den Karten Test und Code: Bestellbestätigung wird OrderConfirmation, Reservierung Reservation.

BestellbestätigungNachricht, dass die Bestellung eingegangen ist; nicht die Rechnung.

  1. Gespräch: weicht abDie Rechnung für B-1042 ist raus.
  2. Ticket: passt zum BegriffAls Kundin erhalte ich nach dem Kauf eine Bestellbestätigung.
  3. Test: weicht absends_invoice_after_order()
  4. Code: weicht abinvoiceService.sendInvoice(order)

3 von 4 Orten meinen Bestellbestätigung, sagen aber etwas anderes.

Wähle einen Begriff und wechsle zwischen uneinheitlich und gemeinsamer Sprache; rot markiert, wo ein Ort ein anderes Wort nutzt.

Glossar des Shops

Glossar des Shops
BegriffPräzise BedeutungGilt inNicht gemeint
BestellungKaufauftrag mit stabiler KennungBestellungWarenkorb
Reservierungzeitlich gebundener Bestand für PositionenLagerphysischer Versand
AutorisierungAnbieter bestätigt den ZahlungsrahmenZahlungbereits eingegangener Geldbetrag
RechnungBeleg einer Forderung mit RechnungsnummerRechnungBestellbestätigung
Das Glossar des Shops legt fest, welcher Begriff was bedeutet und wo er gilt, und ist die Quelle für die Wörter im Bild.

Nutzen & Grenzen

Hilft, wenn

  • Fachgespräche und Code benutzen unterschiedliche Begriffe für denselben Vorgang.
  • Gleiche Wörter führen zu widersprüchlichen Erwartungen zwischen Fachbereichen.

Grenzen

  • Ein globales Glossar kann kontextuelle Bedeutungen vermischen. Verankere die Sprache pro Bounded Context und beschreibe Übergänge gezielt.
  • Umbenennen kostet. Im Code ist es ein Refactoring, bei veröffentlichten APIs und Datenbankspalten deutlich mehr. Innen konsequent umbenennen, an veröffentlichten Verträgen übersetzen; wo die Sprache gilt, klärt der Bounded Context.

In der Praxis

  1. Mehrdeutige Begriffe am Ablauf sammeln. Nutze Event Storming, um etwa „bestätigt“ im Kundenservice und im Zahlungsbereich zu vergleichen. Halte unterschiedliche Folgeregeln als konkrete Klärungsfragen fest.
  2. Bedeutung und Geltungsbereich festlegen. Beschreibe, welche Regel ein Begriff bezeichnet und wo er gilt. Verweise auf den zugehörigen Bounded Context, wenn andere Bereiche das Wort anders nutzen.
  3. Deutsche Fachsprache, englischer Code. Lege die Zuordnung einmal fest, etwa Bestellung zu Order, und halte sie im Glossar fest. Mische die Sprachen nicht: kein BestellungService neben OrderRepository.
  4. Begriffe in der Umsetzung verankern. Nutze die geklärten Namen in Operationen, Ereignissen und Tests. Die gemeinsame Modellarbeit aus Domain-Driven Design hält Sprache und Fachregel synchron.
Ausführliche Erklärung lesen

Fachleute und Entwickler schärfen Begriffe an konkreten Bedeutungen und Zuständen. Dieselben Wörter erscheinen in Gesprächen, fachlichen Kriterien, Tests und im Code, sodass Unklarheiten früh auffallen. Domain-Driven Design verankert diese Zusammenarbeit; Bounded Context begrenzt, wo ein Begriff dieselbe Bedeutung hat.

Eine gemeinsame Sprache ist kontextbezogen und entwickelt sich mit dem Verständnis weiter. Ein Glossar hält Definitionen fest; tägliche Anwendung und gemeinsame Klärung verankern sie im Sprachgebrauch. Wenn zwei Fachbereiche dasselbe Wort unterschiedlich verwenden, sollte die Unterscheidung sichtbar werden, statt künstlich vereinheitlicht zu werden.

Nutze Event Storming, um Begriffe an einem gemeinsamen Ablauf zu erkunden. Halte für „bestätigt“ fest, was Kundenservice und Zahlungsbereich jeweils meinen, und kläre die Bedeutungen mit den Fachrollen, bevor du Namen in Code und Tests verankerst.

Selbst prüfen

Teste dich in drei Stufen

  1. AblesenIm Bild nachsehen

    Welche Orte weichen beim Begriff Bestellbestätigung im uneinheitlichen Zustand ab?

    Lösung mit Begründung ansehen

    Gespräch, Test und Code sprechen von der Rechnung. Nur das Ticket nutzt Bestellbestätigung.

  2. AnwendenAuf eine neue Lage übertragen

    Im Code heißt die Klasse ReservationService, im Ticket steht „Lagerplatz sichern“. Was machst du?

    Lösung mit Begründung ansehen

    Das Ticket auf den Glossarbegriff Reservierung umstellen. Gespräch und Ticket sagen dann Reservierung, Test und Code bleiben bei Reservation.

  3. BewertenEine Alternative abwägen

    Das Team will den Code komplett deutsch benennen und vorhandene API-Felder umbenennen. Wie bewertest du das?

    Lösung mit Begründung ansehen

    Vorteil: weniger Übersetzung im Kopf. Nachteil: Mischung mit englischen Bibliotheksnamen, und umbenannte API-Felder brechen Clients. Empfehlung: Zuordnung festlegen, intern einheitlich benennen, veröffentlichte Felder erst per Übersetzung ändern.

Vertiefen

Diese Bausteine führen die Gedanken dieser Seite weiter.

DomäneDomain-Driven DesignDomain-Driven Design bringt Fachwissen, Sprache und Regeln in ein gemeinsames Softwaremodell.Öffnen DomäneBounded ContextEin Bounded Context legt fest, wo ein fachliches Modell und seine Begriffe gelten.Öffnen DomäneEntities & Value ObjectsEntities und Value Objects unterscheiden Objekte mit eigener Identität von fachlichen Werten.Öffnen

Quellen

Weiter im Lernpfad

Als Nächstes in Domänenmodellierung: Bounded Context.

7 Bausteine

Weiter mitBounded Context