Startseite

Stand: 2020-02-23

DDD Deutsch

Ist Englisch als Implementierungssprache wirklich immer die richtige Wahl?

Auf Deutsch programmieren? Wer macht denn sowas?!

Driven-driven Design (DDD) ist ein Ansatz zur Modellierung komplexer Softwaresysteme. Das Fundament dieses Ansatzes ist die Ubiquitous Language, die allgegenwärtige Sprache. Diese Sprache sprechen alle Beteiligten des Projekts, sie entwickeln sie gemeinsam weiter und sie wird in allen Teilen des Projekts verwendet – sei es in einer Besprechung, in einem Anforderungsdokument, im Code oder in der Datenbank. Für eine Sache wird überall ein und derselbe Begriff verwendet. Eine präzise Sprache ist Voraussetzung für die effektive Gewinnung und Modellierung von Wissen. Deshalb widmet Eric Evans einen guten Teil seines Buches Domain-Driven Design der Ubiquitous Language.

Programmcode wird typischerweise auf Englisch geschrieben. Was ist aber, wenn die Domäne nicht auch englisch ist? Was ist, wenn die Beteiligten alle Dinge und alle Aktionen zum Beispiel mit deutschen Begriffen bezeichnen? Sollten diese Begriffe dann lieber übersetzt werden, damit sie, wie in der Softwareentwicklung üblich, englisch sind? Das würde der Grundidee der Ubiquitous Language und damit des Domain-driven Designs zuwider laufen! Denn dann würden Entwickler eine andere Sprache als die Fachexperten sprechen und das hätte weitreichende Folgen:

Wenn für eine Sache Begriffe aus zwei Sprachen verwendet werden, bemerkt man nicht so leicht, wenn die Bedeutung abweicht. Das führt wiederum leicht dazu, dass auch das Verständnis abweicht. Schon an diesem Punkt hat man einen wesentlichen Vorteil von Domain-driven Design und der Ubiquitous Language verloren, denn dann gibt es eben keine gemeinsame Sprache mehr, die das Verständnis prägt und hilft Fehlentwicklungen zu vermeiden.

Von Begriffsdefinitionen hängt nicht zuletzt die Umsetzung ab. Wenn für eine Sache, ein Begriff A verwendet wird, schließt das möglicherweise eine Eigenschaft ein, die bei dem ähnlichen Begriff B ausgeschlossen wäre. Manchmal wird in Projekten heiß diskutiert, wie etwas benannt werden soll und was genau damit gemeint ist. Es wäre absurd, lange zu diskutieren, ob es A oder B heißen soll, um es dann auf Englisch C zu nennen oder die gleiche Diskussion über den richtigen englischen Begriff erneut zu führen!

Wenn Entwickler und Fachexperten zwei Sprachen sprechen, werden Missverständnisse weniger offensichtlich, was dazu führt, dass die Ubiquitous Language nicht so gut weiterentwickelt wird und Abweichungen von der Realität nicht so schnell bemerkt werden.

Übersetzungen können nicht nur ungenau, sondern auch schlicht falsch sein. Vor ein paar Jahren war ich an einem Projekt beteiligt, in dem wir einen Begriff ins Englische übersetzt hatten und erst später bemerkten, dass der englische Begriff eine ganz andere Bedeutung hatte. Da wir mit dem Kunden aber Deutsch sprachen und im Prinzip auch beim Programmieren auf Deutsch dachten und nur beim Schreiben die Wörter übersetzten, blieb dieser Fehler lange unentdeckt. Dieses Beispiel zeigt auch, dass die Übersetzung in diesem Fall komplett unnötig war.

Das ständige Übersetzen kostet zudem geistige Kapazität, die besser für andere Dinge verwendet werden könnte.

Oder doch Englisch?

Den fachlichen Teil des Codes in der Sprache der Fachexperten (es kann natürlich auch eine andere Sprache als Deutsch sein) zu schreiben, funktioniert natürlich nur, wenn auch wirklich alle Beteiligten diese Sprache sprechen. Falls für die Kommunikation mit den Entwicklern nur Englisch in Frage kommt, würde es kaum Sinn ergeben, wenn diese Entwickler versuchen würden, in einer anderen Sprache zu programmieren. Das Gleiche gilt in internationalen Projekten, wo die Lingua franca in der Regel Englisch ist. Allerdings wären die Diskussionen, in denen das entscheidende Wissen extrahiert und weiterentwickelt wird, dann auch auf Englisch.

Einfach mal auf Verdacht in Englisch zu programmieren, weil ja irgendwann irgendwer vielleicht nur diese Sprache verstehen könnte, wäre vorzeitige Optimierung. Würde man dagegen auf Englisch programmieren, weil man das nun mal so macht, wäre es wohl Cargo-Kult, die Folge von Konformitätsdruck oder beides.

Sprachgrenze

Der wertvolle Kern einer Anwendung besteht aus Fachlogik (Domain) und diesen Teil würde ich aus oben genannten Gründen in der Sprache der Fachexperten schreiben, was in Deutschland eben in der Regel Deutsch ist. Aber sollte der Rest dann auch auf Deutsch sein?

Bei der im Bild dargestellten Clean Architecture (bzw. Onion Architecture) darf ein äußerer Ring einen inneren aufrufen, aber nie andersherum. Man könnte auch sagen, dass die äußeren Ringe auf den inneren aufbauen, also von ihnen abhängig sind. Wenn der Kern deutsch ist, könnte man konsequenterweise auch darauf aufbauende äußere Ringe auf Deutsch programmieren.

Allerdings wird die Anwendung nach außen hin auch immer technischer und auch Software Entwickler haben ihre eigene Ubiquitous Language! Sie reden eben nicht von Ablage oder Speicher sondern von Repository. Ebenso wenig würde man Netzdienst statt Web Service sagen. Deshalb schlage ich vor, technische Sachen in der Sprache der Entwickler, also normalerweise Englisch, zu belassen. Innerhalb der roten gestrichelten Linie wäre also der meiste Code auf Deutsch und außerhalb auf Englisch. Die Kehrseite der Medaille ist ein Mischmasch aus Deutsch und Englisch. Aber wegen dieser kosmetischen Beeinträchtigung sollte man nicht die Sprache der wertvollen Domäne an die Sprache der Entwickler anpassen!

In seinem Buch Clean Architecture nennt Robert C. Martin Application Services (ein DDD-Begriff) Use Cases, die den Entwickler “anschreien” sollen (Kapitel 21, “Screaming Architecture”). Diese Anwendungsfälle sollen die wichtigsten Orientierungspunkte in der Architektur sein, was dafür spricht, sie ebenfalls in der Sprache der Fachexperten, in meinem Beispiel also Deutsch, zu verfassen. Alles was noch weiter außen ist (die genaue Anzahl der Ringe ist nicht festgelegt), dürfte dann eher technisch sein, weshalb dort Englisch normalerweise die passende Sprache wäre.

Weitere Information