Jede Software hat das Ziel, Probleme innerhalb eines Fachgebiets – der Domäne – für ihre Nutzer zu lösen. Beim Domain-Driven Design (kurz DDD) geht es nicht nur um die technische Umsetzung, sondern auch um unsere Denkweise beim Entwurf des Systems. DDD zusammen mit CARDS+ eröffnet weitere Optionen. Fachklassen (Entity und Aggregate) aus dem DDD sind eine ideale Ergänzung zum entsprechenden Begriff im Glossar. Das ist immens wichtig für die Bildung eines gemeinsamen Vokabulars im Projekt. Die gemeinsame Sprache ist ein wichtiges Ziel von CARDS+ und DDD.

Gemeinsame Sprache

Eine Übersetzung von Fachbegriffen einer beispielsweise deutschsprachigen Projektorganisation ins Englische widerspricht der Idee, dass Entwickler und Domänenexperten die selbe Sprache sprechen. Spannend ist daher die Frage, ob wir trotzdem bei der Implementierung des Domänenmodells die Begriffe ins Englische (der lingua franca der Entwickler) übersetzen sollen. Meine persönliche Empfehlung ist, keinen Begriff der Domäne zu übersetzen. Um meine Empfehlung zu unterstreichen, möchte ich ein paar Beispiele aus der 100-jährigen Geschichte der DB aufzählen. Vieles im “Bahndeutsch” ist so spezifisch, dass es bei anderen Verkehrsunternehmen nicht zu finden ist, es also auch keine richtige Übersetzung gibt.

Der Begriff Zugfahrt lässt sich mit “train ride” und “train run” übersetzen. Der Unterschied ist, dass “train ride” die Zugfahrt aus Sicht eines Reisenden ist, während “train run” die betriebliche Sicht darstellt. Das DB Language Portal hingegen übersetzt Zugfahrt mit “train movement” oder ” train journey”.

Die naheliegende Übersetzung “train number” funktioniert, hat aber in anderen Ländern verschiedene Bedeutungen:

  • Großbritannien: Es gibt keine Zugnummern. Wird vermutlich als verunglückte Übersetzung von “train headcode” verstanden, ein rein betrieblicher Code für einen Zug, z.B. “1X01”.
  • Indien: Die Zugnummer ist eine Art Katalognummer im Kursbuch.
  • USA: Ein bisschen wie in Indien, aber viel wichtiger scheint hier der Name des Zuges zu sein.

Eine mögliche Übersetzung ist “service category”. Das trifft es ganz gut, führt jedoch zu Verwirrungen, da die Gattung in Deutschland auch zur Darstellung tariflicher Eigenschaften dient (IC-Garnitur, die teilweise als RE fährt). In anderen Ländern beschreibt sie ausschließlich die Grundausstattung eines Zuges.

Das Englische kennt keine Unterscheidung zwischen dem Halt (d.h. der Tatsache, dass ein Fahrzeug an einem Ort geplant stehenbleibt) und der Haltestelle (d.h. einem Ort, an dem solche Halte stattfinden können). Beides heißt “stop”

Sowas gibt es in Deutschland, rudimentär in England und sonst nirgendwo auf der Welt.

Numerische Codierung für Wochen- und Feiertage, die außerhalb der DB niemand kennt.

Die Beispiele zeigen doch sehr eindrucksvoll, dass ein Begriff einer deutschsprachigen Domäne nicht immer eindeutig ins Englische übersetzt werden kann. Und warum sollten wir das auch?

Korrekte Sprache

Eine gute Übersetzung erfordert ein gewisses Maß an Kenntnissen der Fremdsprache. Auch wenn in Deutschland jeder Entwickler die Sprache Englisch mehr oder weniger beherrscht, kommt es doch sehr häufig zu falschen Übersetzungen. Oft ist das von beliebten Übersetzern wie leo.org oder dict.cc angebotene Wort nicht das richtige für die Domäne des Projektes. Für Spezialbegriffe oder zusammengesetzte Begriffe haben Übersetzer in vielen Fällen kein Ergebnis. Ein selbst zusammengesetztes Fremdwort ist die schnelle Lösung, mit dem Resultat, dass diese “Wortschöpfung” manchmal gar kein korrektes Wort in der englischen Sprache ist. Ich selbst beherrsche Englisch so gut, dass ich jedes englischsprachige Fachbuch oder Magazin lesen und verstehen kann. Vorträgen auf Konferenzen kann ich bei voller Konzentration gut folgen. Ich kann mich in Gesprächen ausreichend gut ausdrücken, spreche fließend. Ich kann aber für mich festhalten, dass ich nicht immer die korrekte Übersetzung erkenne, wenn mir Übersetzer ein Liste von Möglichkeiten anbieten. Ich habe anders als bei meiner Muttersprache Deutsch kein “Bauchgefühl”, das mir sagt, was das richtige englische Wort ist.

Gemischte Sprache im Code

Nehmen wir jetzt einfach an, dass wir entscheiden, die Fachbegriffe für den Code nicht zu übersetzen. Die Folge dieser Entscheidung ist natürlich Code in einem Sprachenmix mit Elementen der Programmiersprache (englisch, z.B. interface, class, if, for, while), mit Verben für Methoden (englisch, z.B. get, set, collect) und Entwurfsmuster (englisch, z.B. Repository, Entity, Event) und den Fachbegriffen (deutsch). Ich persönlich finde das Ergebnis nicht schlimm. Im Gegenteil. Durch den Sprachenmix erkennen wir die Fachbegriffe sogar noch deutlicher. Klassen, Typen und Methoden mit fachlichen Hintergrund sind gut erkennbar.

Sehr vorteilhaft in diesem Zusammenhang ist die Vermeidung der Pluralbildung der deutschen Fachbegriffe im Code. Selbst mit einer sehr guten Begriffsdefinition im Glossar inklusive korrekter Übersetzung ins Englische (was wie gesagt schon sehr anspruchsvoll und arbeitsintensiv ist) wird es Menschen, die nicht deutsch sprechen, kaum gelingen, Fachbegriffe im Plural zu verstehen. Ein praktische Lösung zur Vermeidung des Plural von Fachbegriffen basiert auf der Verwendung des Präfix “All” in allen Fällen, wo wir einen Namen für eine Menge brauchen. Wir können das Schema bekannter Entwurfsmuster für Methoden ohne Einschränkungen auch mit deutschen Fachbegriffen umsetzen.

Ich habe es persönlich erlebt, dass Kollegen aus einem Offshore-Team in Indien ganz natürlich die deutschen Begriffe “Zug” und “Fahrt” verwenden. Die zusammengesetzte Form “Zugfahrt” stellt auch kein Problem dar. Doch der deutsche Plural “Züge” ist problematisch. Der Umlaut ist ein wesentliches Hindernis für das Verständnis. Auch “Zugfahrten” als Plural des zusammengesetzten Wortes ist problematisch.

Nehmen wir an, eine Zugfahrt hat Abschnitte. Die Relation von Zugfahrt zu Abschnitt wird in einer konkreten Java-Klasse als Collection vom Typ “List” realisiert. Ein Getter heißt dann “getAllAbschnitt”. Der Vorteil bei der Verwendung von “All” als Präfix ist, dass der Begriff, hier “Abschnitt”, unverändert im Namen von Attributen und Operationen erhalten bleibt.

ktip Die Variante “getAbschnittList” verfolgt das gleiche Ziel. Der Nachteil ist aber die Festlegung auf den Typ “List”. Nehmen wir an, wir ändern die Implementierung auf den Typ “Set”, dann müssen wir die Methode in “getAbschnittSet” umbenennen, um konsistent zu bleiben.

Weitere Beispiele für Kombinationen aus deutschem Fachbegriff und englischem Code gibt es bei einem DAO. Die Methode zum Laden einer einzelnen Zugfahrt heißt “loadZugfahrtById”, die Methode zum Lader aller Zugfahrten “loadAllZugfahrt”. Die Methode “findAll” ist in jedem generischen DAO vorhanden.

Ein weiterer Vorteil dieser Praxis entsteht bei Worten, deren Plural sich nicht vom Singular unterscheidet (z.B. das englische Wort “information” oder das deutsche Wort “Wasser”) oder bei denen der Plural eine andere Bedeutung hat (z.B. das Wort “Geld” bzw. “Gelder”).

Das Wort gibt es in deutscher und englischer Sprache. Ein wesentlicher Unterschied ist aber, dass es im Englischen keinen Plural gibt. Das englische Wort “informations” ist nicht korrekt, während es das deutsche Wort “Informationen” sehr wohl gibt. Nehmen wir an, wir haben eine Klasse “Information”. Ein Getter, der eine Menge Objekte von diesem Typ liefert, heißt üblicherweise “getInformations”, was aber rein sprachlich falsch ist. Die Verwendung von “getAllInformation” ist eine elegante Lösung für beide Sprachen.

Das Wort “News” hat sich im deutschen Sprachraum schon längst als Begriff für Nachrichten durchgesetzt. Nehmen wir an, wir haben eine Klasse “News”. Ein Getter, der ein einzelnes Objekt von diesem Typ liefert, heißt üblicherweise “getNews”. Das ist aber gleichzeitig auch der Name des Getter, der eine Menge Objekte von diesem Typ liefert. Die Verwendung von “getAllNews” ist eine klare Lösung.

Auch ein Eigenname der Domäne mit großer fachlicher Bedeutung hat nicht immer einen sinnvollen Plural. Für so einen Eigennamen gibt es keine exakte Übersetzung. Das Präfix “All” funktioniert hier gleichermaßen für jede Sprache.

Lesbarer Code

CARDS+ verfolgt wie jede agile Methode das Ziel, dass ein cross-funktionales Team den Wert funktionierender Software höher bewertet als umfassende Dokumentation. Darum ziehen wir speziell in der Architekturdefinition eine klare Grenze: Wenn lesbarer Code einen technischen Sachverhalt eindeutig beschreibt, dann werden wir keinerlei Zusatzdokumentation, keine Wiederholung in Prosa im Wiki schreiben. Um aber alle Zielgruppen der Produktdokumentation zu erreichen, muss dieser Code auch für Personen lesbar sein, die keine Entwickler oder Software-Experten sind. Um dieses Ziel zu erreichen, sind nicht übersetzte Fachbegriffe im Code ein nicht zu unterschätzender Vorteil. Denn der Product-Owner und Business-Analysten sind in der Lage, einfache Java-Klassen (z.B. ein POJO), eine Konfigurationsdatei oder eine Schemadefinition zu “lesen”. Dafür muss niemand programmieren können.

ktip Es gibt Werkzeuge, die UML-Klassendiagramme direkt aus Code generieren können, z.B. AgileJ StructureViews für Java. Der automatisierte Einsatz solcher Werkzeuge kann eine Lösung für Zielgruppen sein, die Code nicht lesen können, aber Zugriff auf dieses sehr detaillierte Produktwissen brauchen.

Fazit

In letzter Zeit stelle ich fest, dass Teams die Vorteile der Verwendung der Begriffe der Domäne ohne Übersetzung erkennen. Trotz ausreichender Kenntnisse der englischen Sprache schätzen manche Entwickler die Sicherheit bei der Verwendung der Begriffe in ihrer Muttersprache, eingebettet in Code, den sie ohne Nachdenken verstehen. Trotzdem erlebe ich immer wieder emotionale Diskussionen bei der Frage Übersetzung ja oder nein. Es gibt Entwickler, die sich Code nur in Englisch vorstellen können. Sie finden deutsche Klassennamen unzumutbar, grausam, inkorrekt. Ein Sprachenmix aus deutschen Begriffen ohne Plural mit englischen Verben (z.B. loadZugfahrtById oder loadAllAbschnitt) und Stereotypen (z.B. ZugfahrtRepository) stellt für mich kein Problem dar. Und das Glossar schafft die Voraussetzung, dass bei einer unerwarteten internationalen Ausrichtung (z.B. wegen überraschendem Erfolgen mit dem Produkt) internationale Teams nur die Begriffe lernen müssen, um die Software zu verstehen. Auch das verstehe ich eindeutig als Vorteil.