Deutsche Fachsprache, englischer Code: Wo verläuft die Grenze?

Die unbewusste Entscheidung zwischen Fachsprache und Code

In der modernen Softwareentwicklung klafft oft eine Lücke zwischen der fachlichen Modellierung und der technischen Umsetzung. Nach intensiven Workshops, in denen Fachabteilungen und Entwickler gemeinsam Begriffe wie „Rechnungsstellung“, „Mahnlauf“ oder „Storno“ definieren, findet sich diese Präzision im Quellcode häufig nicht wieder. Stattdessen werden diese Begriffe bei der Implementierung oft ungeprüft ins Englische übersetzt. Golo Roden, CTO von the native web GmbH, weist darauf hin, dass dieser Übergang meist unbewusst geschieht. Entwicklerinnen und Entwickler neigen dazu, aus Gewohnheit englische Bezeichner zu wählen, da die gesamte technische Infrastruktur – von Programmiersprachen über Frameworks bis hin zur Dokumentation – auf Englisch basiert. Diese Entscheidung, die selten explizit getroffen wird, führt jedoch dazu, dass wertvolles fachliches Wissen verloren geht. Wenn der Code die feinen Nuancen der Fachsprache nicht mehr abbilden kann, entstehen Missverständnisse, die erst Monate oder Jahre später zutage treten und dann mit hohem Aufwand korrigiert werden müssen. Der Artikel beleuchtet, warum dieser Reflex zwar technisch nachvollziehbar, aber fachlich oft problematisch ist.

Gründe für den englischen Reflex und seine Grenzen

Der Reflex, im Code ausschließlich Englisch zu verwenden, ist tief verwurzelt. Entwickler lernen ihr Handwerk durch englischsprachige Quellen wie Stack Overflow, Framework-Dokumentationen und die Syntax der Programmiersprachen selbst. Es ist daher naheliegend, dass Begriffe wie „createInvoice“ natürlicher erscheinen als „rechnungErstellen“. Ein häufig genanntes Argument ist die internationale Lesbarkeit des Codes. Roden gibt zu bedenken, dass dieses Argument in vielen Fällen unbelegt bleibt, insbesondere wenn Teams über Jahre hinweg in derselben Stadt und mit denselben Personen arbeiten, die ihre Anforderungen ausschließlich auf Deutsch erhalten. Zudem schwingt oft der Wunsch nach Professionalität mit: Englische Begriffe wirken in der Wahrnehmung vieler Entwickler wie „echte Software“, während deutsche Begriffe als Provisorien wahrgenommen werden. Diese Einschätzung ist jedoch rein subjektiv und lässt die fachliche Korrektheit außer Acht. Während technische Komponenten wie ein „HttpClient“ zweifellos englische Namen tragen sollten, wird der Reflex dort teuer, wo er auf die eigentliche Fachlichkeit trifft. Die Grenze zwischen Technik und Fachdomäne ist fließend, was den unbewussten Sprachwechsel besonders tückisch macht.

Die Gefahr des Informationsverlusts bei der Übersetzung

Die Diskussion um die Sprachwahl verkommt oft zu einem Streit über Ästhetik, bei dem es um Denglisch, Umlaute oder den persönlichen Geschmack geht. Roden schlägt einen Test vor, um zwischen Stilfragen und Modellierungsfragen zu unterscheiden: Wenn durch eine Übersetzung keine fachliche Unterscheidung verloren geht, handelt es sich um eine Stilfrage, die innerhalb des Teams geklärt werden kann. Gehen jedoch Nuancen verloren, liegt eine Modellierungsfrage vor. Ein klassisches Beispiel ist der Begriff „Verfügbarkeit“. Im Englischen wird „availability“ oft als Übersetzung genutzt, doch dieser Begriff kann im Deutschen sowohl „Verfügbarkeit“ als auch „Einsatzbereitschaft“ abdecken. In einer Domäne, in der ein Fahrzeug zwar verfügbar, aber nicht einsatzbereit sein kann, führt die pauschale Übersetzung zu einem fachlichen Informationsverlust. Ähnliches gilt für Begriffe wie „Auftrag“, „Bestellung“ und „Abruf“, die im Deutschen unterschiedliche Rechtsfolgen haben, im Code aber häufig alle zu „order“ verkürzt werden. Dieser Verlust ist deshalb so heimtückisch, weil er zunächst nicht auffällt. Erst wenn das System erweitert werden soll oder Fehler in der fachlichen Auswertung auftreten, zeigt sich das Problem, das durch keine automatisierte Prüfung erkannt werden kann.

Fachsprache als gesetzliche Anforderung

In manchen Bereichen ist die Verwendung der Fachsprache nicht nur eine Frage der Präzision, sondern eine zwingende Anforderung. Begriffe wie „Umsatzsteuer“ oder „Vorsteuer“ sind fest in Rechtsordnungen verankert. Eine Übersetzung in „VAT“ oder andere englische Äquivalente ist oft inhaltlich falsch, da die rechtlichen Rahmenbedingungen, Fristen und Ausnahmen nicht deckungsgleich sind. Auch Begriffe wie „Mahnbescheid“, „Kündigungsfrist“ oder „Betriebsrat“ haben keine direkten englischen Entsprechungen, die dieselben Befugnisse oder rechtlichen Konsequenzen abbilden. Wer hier übersetzt, entfernt sich von der Rechtslage. Roden beschreibt, wie in solchen Fällen oft eine Person als „Übersetzer“ im Kopf fungiert, die zwischen dem deutschen Fachbegriff und dem englischen Code vermittelt. Fällt diese Person aus, beginnt eine mühsame archäologische Arbeit, um die fachliche Bedeutung hinter den technischen Feldern zu rekonstruieren. Besonders in der Schweiz, wo Gesetze in drei Sprachen gleichermaßen verbindlich sind, zeigt sich, dass ein Modell mehrere fachliche Vokabulare gleichzeitig abbilden muss, anstatt sie auf einen englischen Nenner zu reduzieren.

Ein Kriterium für die Grenzziehung

Um die Frage zu beantworten, wo die Grenze zwischen deutscher Fachsprache und englischem Code verlaufen sollte, schlägt Roden ein klares Kriterium vor: Ein Name gehört in die Domänensprache, wenn Fachexperten ihn korrigieren könnten. Wenn man einem Experten den Begriff „RechnungAusgestellt“ vorlegt, kann dieser beurteilen, ob der Begriff fachlich korrekt ist oder ob er sich von der „Rechnungsstellung“ unterscheidet. Bei einem „HttpClient“ hingegen kann der Fachexperte nicht urteilen, da der Name keine Bedeutung in seiner Domäne hat. Dieser „Vorlesetest“ ermöglicht eine saubere Trennung: Aggregate, Events, Commands und fachliche Zustände sollten die Domänensprache tragen, während technische Bausteine, Frameworks, Logs und Metriken englisch bleiben. Gemischte Bezeichner wie „RechnungRepository“ sind nach dieser Logik kein Fehler, sondern machen die Schnittstelle zwischen fachlicher Welt und technischer Umsetzung sichtbar. Auch wenn dies ästhetisch nicht jedem gefällt, ist es ehrlicher als der Versuch, alles in eine Sprache zu zwingen, die der fachlichen Komplexität nicht gerecht wird.

Offene Fragen und die Rolle der Dokumentation

Der Quelltext lässt einige Aspekte offen, die über die reine Namensgebung hinausgehen. So wird nicht detailliert darauf eingegangen, wie mit bestehenden, historisch gewachsenen Codebasen umgegangen werden soll, in denen bereits eine konsequente englische Benennung etabliert wurde. Auch die Frage, wie man mit internationalen Teams verfährt, in denen kein Mitglied Deutsch als Muttersprache spricht, wird nur am Rande durch das Argument der Lesbarkeit gestreift, ohne eine konkrete Lösung für die fachliche Präzision in solchen Konstellationen anzubieten. Zudem bleibt unklar, welche Auswirkungen eine strikte Trennung auf die Tooling-Landschaft hat, etwa bei der automatischen Generierung von Dokumentationen oder bei der Integration von Drittanbieter-Bibliotheken, die ausschließlich englischsprachige Schnittstellen bereitstellen. Roden stellt klar, dass Kommentare, Commit-Messages und Dokumentationen anders zu bewerten sind als Bezeichner im Code. Da sich diese Texte übersetzen lassen, ohne dass fachliche Unterscheidungen verloren gehen, fallen sie unter die Kategorie der Konventionen, die das Team intern festlegen kann.

Die Konsequenzen für die Softwarearchitektur

Die Entscheidung für oder gegen die deutsche Fachsprache im Code hat direkte Auswirkungen auf die Wartbarkeit und die Fehleranfälligkeit von Systemen. Wenn die Sprache des Codes nicht mit der Sprache der Fachabteilung übereinstimmt, entsteht eine kognitive Dissonanz. Entwickler müssen bei jeder Änderung übersetzen, was das Risiko für Fehlinterpretationen erhöht. Roden betont, dass Softwareentwicklung kein Selbstzweck ist, sondern immer einer fachlichen Logik folgen muss. Wenn die Fachlichkeit im Code „versteckt“ oder durch ungenaue Übersetzungen verfälscht wird, leidet die Qualität des gesamten Systems. Die Architektur sollte daher so gestaltet sein, dass sie die fachlichen Begriffe als „First-Class Citizens“ behandelt. Das bedeutet, dass die Domänensprache im Code präsent sein muss, um sicherzustellen, dass das System eine korrekte Geschichte erzählt und nicht nur technische Daten verwaltet. Die Trennung in fachliche und technische Anteile, wie sie durch das Kriterium der Korrigierbarkeit durch Experten vorgeschlagen wird, ist ein Weg, um diese fachliche Integrität langfristig zu bewahren und die Kommunikation zwischen den Beteiligten zu verbessern.

Ausblick auf die tägliche Praxis

Für die tägliche Arbeit bedeutet dies, dass Teams ihre Konventionen zur Namensgebung kritisch hinterfragen sollten. Es geht nicht darum, dogmatisch alles auf Deutsch zu schreiben, sondern darum, die fachliche Präzision zu priorisieren. Der Prozess der Modellierung sollte nicht mit dem Whiteboard enden. Vielmehr muss die Sprache des Modells in den Code einfließen. Roden plädiert für einen bewussten Umgang mit Begriffen. Wenn ein Begriff im Workshop eine spezifische Bedeutung hat, sollte er im Code exakt so abgebildet werden, auch wenn er deutsch ist. Die Diskussion über Umlaute oder „schönere“ englische Namen sollte dabei als das erkannt werden, was sie ist: eine untergeordnete Stilfrage. Die wichtigere Aufgabe ist es, sicherzustellen, dass der Code die fachlichen Unterscheidungen widerspiegelt, die für den Geschäftsprozess entscheidend sind. Indem man den Fachexperten eine aktive Rolle bei der Validierung der Bezeichner einräumt, lässt sich die Qualität der Software nachhaltig steigern und die Lücke zwischen technischer Implementierung und fachlicher Anforderung schließen.