André Krämers Blog

Lösungen für Ihre Probleme

Umfrage: Zieht DDD eine deutsche Benennung für Klassen und deren Member nach sich?

27 Nov 2009

Bis vor kurzem hätte ich die Frage, ob Klassen, Methoden, Eigenschaften und Variablen innerhalb eines Quellcodes Deutsch oder Englisch benannt werden sollen ohne zu zögern mit “Natürlich Englisch” beantwortet.

Mittlerweile bin ich mir dessen nicht mehr so sicher. Seit einiger Zeit befasse ich mich nun mit Domain-Driven-Design und damit verwandten Themen. In der meist englischen Literatur bzw. Blog Beiträgen wird stets darauf hingewiesen, dass man im DDD komplett in die Domäne des Kundens eintauchen und dessen Sprache sprechen sollte.

So schreibt Gojko Adzic zum Beispiel in seinem Buch Bridging the Communication Gap, dass man als Entwickler nicht mit technischen Bezeichnungen arbeiten und diese für den Kunden übersetzen, sondern durch das ganze Projekt hindurch die (Geschäfts-)sprache des Kundens nutzen soll.

Gerade im englischsprachigen Raum kann ich mir dies auch problemlos vorstellen. Wenn bei meinen Kunden ein Artikel in einer Bestellung zum Beispiel Order Item genannt wird, hätte ich auch kein Problem damit, eine Klasse OrderItem in meinem Code anzulegen. Auch Methoden wie GetOrderItemById, oder GetOrderItemByName würde ich ohne zu zögern in einem Repository unterbringen.

Was aber, wenn wir im deutschsprachigen Raum arbeiten? Der domänenspezifische Begriff des Kundens wäre zum Beispiel Bestellposition.

Heißt dies nun, dass ich eine Klasse Bestellposition anlegen sollte? und ein BestellpositionenRepository? Mit den Methoden GetBestellpositionById und GetBestellpositionByName?

Für mich persönlich klingt dies unheimlich grausam. Natürlich könnte ich die Methoden auch HoleBestellPositionAnhandDerId oder HoleBestellPositionAnhandDesNamens nennen. So würde die vermischte Schreibweise zumindest entfallen. Trotzdem würde ein solcher Code, der englische Schlüsselwörter mit deutschen Klassen und Membern vermischt, eigenartig und fremd auf mich wirken.

Auf der anderen Seite habe ich auch schon genug Situationen erlebt, in denen man das korrekte englische Wort zum Domänenbegriff des Kundens einfach nicht kannte. Also ging man schnell zu leo, um dort eine Übersetzung nachzuschlagen. Ergebnis war dann häufig, man entweder eine unpassende und eher komische Übersetzung benutzte, oder aber andere Entwickler gar nicht wussten, was dieser eigenartige englische Begriff bedeuten könnte. Im schlimmsten Fall ging ein anderer Entwickler also auch zu leo und suchte sich dort eine andere Übersetzung heraus. So habe ich zum Beispiel mehrere Jahre in einem Projekt gearbeitet, in dem für den Deutschen Begriff Artikel die englischen Begriffe Article, Part und Material genutzt wurden. Wie man sich vorstellen kann, trug das nicht gerade zur Lesbarkeit des Codes bei.

Von daher meine Frage an die Community: Wie geht ihr in deutschen Projekten vor? Deutsche Namen? Englische Namen? Beides wild gemischt?

Über zahlreiche Kommentare oder auch Blogantworten würde ich mich sehr freuen!

Es gibt 10 Kommentare

Von Rainer Hilmer | 29.10.2011 21:11

Mir geht es so wie dir und ich denke mal, die Autoren der DDD-Literatur, so weit ich weiß alle aus dem englisch-sprachigen Raum, haben sich keine Gedanken darüber gemacht, wie ihre Empfehlungen denn in anderen Ländern aussehen würden. Wie auch immer, ich finde Sprachenmischmasch grauslich, und solange ich die Wahl habe, werde ich mich weigern so etwas zu produzieren. Mir würde es gefallen wenn man sich in der Entwicklerbranche international auf englisch festlegen würde, so wie in der Avionik.GrußRainer Hilmer

Von Golo Roden | 29.10.2011 21:11

Hallo,ich schließe mich Rainer an - diesen Sprachenmix finde ich ebenfalls grausam. Komplett alles auf Deutsch zu machen halte ich auch für unpraktikabel, da über kurz oder lang potenziell doch einmal länderübergreifend entwickelt werden könnte. Zudem haben sich gewisse Begriffe auch einfach eingeprägt, und hier verwirrt es mehr als dass es nützt, wenn man diese ins Deutsche nachzieht.Auf der anderen Seite kann ich auch die Einwände gut nachvollziehen, dass es schwierig ist, domänenspezifische Begriffe treffend zu übersetzen.Abhilfe schafft hier IMHO ein zentral gepflegter, für alle Entwickler verbindlicher Glossar, der die englischen Fachbegriffe als im Projekt verwendete Übersetzung auflistet.So etwas findet sich auch in diversen Fachbüchern von Microsoft Press, für Windows: Heißt "Login" (oder "Logon"?) eigentlich "Benutzername", "Anmeldename", ...? "Password" = "Passwort" oder "Kennwort"? ...Viele Grüße,Golo

Von christoph | 29.10.2011 21:11

Ich finde, dass man mit dem Kunden absprechen sollte, welche Termini festgelegt werden sollten und dabei die Vor- und Nachteile genau abwägen. Da viele Firmen heute international aufgestellt sind, wäre eine englische Benennung, wenn irgentmöglich, vor zuziehen.

Von Stefan Lieser | 29.10.2011 21:11

Hi,ich möchte mich als Vertreter der "allgegenwärtigen Sprache" zu Wort melden. Wenn die Domäne des Kunden deutsche Begriffe verwendet, verwende ich diese ebenfalls. Eine Übersetzung ins Englishe widerspricht der Idee, dass Entwickler und Domänenexperte die selbe Sprache sprechen sollten. Gerade _weil_ andernfalls nämlich wieder eine Übersetzung fällig ist. Und in der Tat: oft gibt es keine passende 1:1 Übersetzung, das führt dann schnell zu Misverständnissen und gerade die will die ubiquitous language ja vermeiden.Vorbereitungen zu treffen, weil evtl. mal länderübergreifend entwickelt wird, halte ich für den falschen Reflex. YAGNI.Zur Benennung im Quellcode: die Signatur 'Kunde GetKundeById(int id)' finde auch ich grauslich. Aber wie wäre es mit 'Kunde KundeMitId(int id)'?Viele GrüßeStefan

Von Ilker Cetinkaya | 29.10.2011 21:11

Englisch, außer es ist expliziter Kundenwunsch. Bei DDD ist "Wording" wie auch bei BDD eine wichtige Komponente.Dennoch würde ich nicht soweit gehen, alles auf die Waagschalte legen und strikt nur noch in der Sprache meines "Domäneninhabers" sprechen. Schlußendlich interessiert es mich primär, die Domäne und den Code zu verstehen. Also schreibe ich das auch so runter - in Englisch. Ergo: bei mir heißt es definitiv GetCustomerById und nicht KundeMitId. Englisch ist gängig, ja ich würde sagen de-facto Standard. Es hilft bei vielen Dingen: einheitliche Termini, Code Reviews, Fluent Reading. All das ist in vielerlei Hinsicht praktikabel und stört ja auch nicht das Verständnis. Im Gegenteil.Bgzl. Deiner Bedenken wg. der Schwiergikeit, die korrekte "Übersetzung" zu finden kann ich nur sagen - du bist nicht allein. Es ist völlig normal. Vielleicht verwundert es im ersten Augenblick - aber auch Amerkaner und Engländer haben dieses Problem.Es geht dabei nicht nur um die "passende" Übersetzung, sondern schlichtweg einfach um einen konventionalisierten Ausdruck. Ich habe schon mit Amerikanern Code produziert, wo es wild durcheinander ging: "Car", "Vehicle", "Item", "Part", "Bike", "Motor", "Board", "Storage", "Repository", "Store", "Drawer", "Folder", "Directory", "Private", "Personal", "Secret", "Confident", "Sensible", usw. usf. Es geht im Endeffekt darum, ein Glossar zu haben. Das kann man IMHO mit BDD und User Stories sehr schön und einfach in den Griff bekommen. Schon dort legt man die Begriffe fest und gut is.My 2c :-)Ilker

Von http://jcselke.blogspot.com/ | 29.10.2011 21:11

Hallo,den Ansatz des Englischen mit entsprechendem Glossar finde ich auch sehr attraktiv.Meines Erachtens sollte es aber sehr gut und eng mit dem Kunden erarbeitet und abgestimmt sein. Es handelt sich schließlich um seine Sprach-Domäne nicht nur um bloßes "Wording" und damit ist es die Basis für ein gemeinsames Verständnis und erfolgreiche Kommunikation.Ich würde nicht so weit gehen "eine Sprache zu sprechen", auch mit der Landessprache zu besetzen. Für mich ist es eher ein Sinnbild für ein gemeinsames Verständnis von Schlüsselbegriffen und damit der Sprachbasis.Auch wenn Englisch "für uns" eine Art de-facto Standard darstellt, sollte der englische Sprachgebrauch im Kundenumfeld nicht außer Acht gelassen werden. Er ist dort z.T. nicht so üblich...Viele Grüße,Jan

Von André Krämer | 29.10.2011 21:11

@Rainer und GoloExakt das was ihr sagt, war auch mein bisheriger Ansatz. Die Beschäftigung mit DDD, hat aber genau diese Sichtweise für mich persönlich ins Wanken gebracht.@ChristophGuter Punkt. Spricht aber auch wieder dafür, im Zweifelsfall deutsch zu entwickeln.@StefanDeine Argumente sind genau die, die der Auslöser für meine Fragestellung waren. Missverständnisse zwischen Kunden und Entwicklern (aber auch Entwicklern untereinander) reduzieren, indem die Fachbegriffe des Kundens durchgängig während der Entwicklung genutzt werden. Interessant auch, dass du mit Eric Evans darüber gesprochen hast. Wäre vielleicht mal ein Blog Eintrag deinerseits wert ;-) Kunde KundeMitId ist zwar gewöhnungsbedürftig, klingt aber viel Besser als GetKundeById oder HoleKundeAnhandDerId.Was ich mich nun auch noch frage: Wie hälst du es mit Klassen / Methoden, die rein technischer Natur sind und für die es kein Gegenstück auf der Kundenseite gibt. Sprich hast du zum Beispiel keine Logging, sondern eine Protokollier Klasse? Würde ein ShoppingBasketService bei dir WarenkorbDienst oder WarenkorbService heissen?@IlkerIm Prinzip vertrittst du eine ähnliche Sichtweise wie Rainer und Golo und somit auch mein altes Weltbild. Wenn du, wie in deinem Beispiel mit Amerikanern Code fabriziert hast, in dem es mal "Car", mal "Vehicle" war, spricht dies für mich, dass ihr dort aber auch nicht mit den Fachbegriffen des Kundens hantiert habt, oder? Genau das soll ja durch die durchgängige Nutzung der Kundenbegriffe vermieden werden, dass es mal "Car" und mal "Vehicle" ist.Einen guten Einwand gegen Deutsche Übersetzungen finde ich den Punkt "fluent reading". Du hast damit sehr schön auf den Punkt gebracht, was wir anderen wohl meinten als wir sagten: "Klingt einfach furchtbar" ;-)@JanSo ist es: Für uns ist englisch alltäglich, für unsere Kunden jedoch nicht. Denkt man den Gedanken weiter, bedeutet dies, dass man stets einen "Übersetzer" zwischen Kunden und Entwickler braucht. Oder man macht es sich einfach und gibt dem Kunden das Glossar an die Hand.

Von Jan Christian Selke | 29.10.2011 21:11

Interessant finde ich, ehrlich gesagt, den Aspekt, dass die gesamte Diskussion aus Sicht des Entwicklers geführt wird.In letzter Instanz handelt es sich aber, gerade dann und weil ein Kunde mit im Boot sitzt, in der Regel um Auftragsarbeiten. Das wiederum bedeutet, die Entwicklung ist kein Selbstzweck. Gerade im behördlichen Umfeld ist Englisch nicht zwingend auf der Tagesordnung und darüber hinaus wird sogar deutscher Quellcode (vertraglich?!) gefordert. Das ist mit Sicherheit ein Punkt, dem wir Entwickler uns gerne versperren und dem so entgegen gesteuert werden könnte.Grundsätzlich finde ich den Gedanken deutschen Quellcode zu schreiben auch charmant.Meine Frage allerdings: Wie verhält es sich mit internationalen Entwicklerteams in einer monolingualen Kundendomäne? Wir können zwar alle Englisch, aber was würde der "berühmte Inder" mit einer Methode "KundeMitId" anfangen?

Von Rainer Schuster | 29.10.2011 21:11

Für mich eine klare Sache, wie Stefan es schon gesagt hat: Entitäten in der Domänensprache. Ich denke wir sprechen hier von den Entitäten. Bei allen anderen Klassen (wie der im Beispiel genannte Logger) eben wieder auf englisch. Ich schreibe meine Entitäten, das sind bei mir die Nomen, in der Domänensprache. Die Verben oder auch Prädikate, also alles was Verhalten beschreibt, hat meistens keinen direkten zusammenhang mit der Domäne, sonder ist eher technischer Natur und beschreibt die Art und Weise dessen, was ich ES "im Code" mache um das Ziel xy der Problemdomäne zu lösen.Was ist für mich richtig:- GetKontaktpersonByID - KontaktpersonPrinter (verhalten, das in eine Klasse gesteckt wird)- KontaktpersonReaderusw. Prinzipiell, wenn ich das Single Responsibility Principle verfolge (nur eine Zuständigkeit) lässt sich das Muster von "Verhaltensklassen" gut mit folgender Konvention umsetzen. Wollen wir etwas lesen (read) brauchen wir also einen reader. -> Entität + Verb + "er" = Klassenname. z.B. KontaktpersonReader.Wenn wir allgemeines verhalten beschreiben, also etwas generische haben, dann fällt die Frage sowieso weg -> z.B. Logger. Oder eine spezielle Implementierung KontaktpersonLogger.So gibt es noch mehr Möglichkeiten, sind einfach an Konventionen zu halten und dabei elegante Bezeichnung für sauberen Code zu finden. Ob das DDD, BDD oder was-weiss-ich für Driven Design ist ganz egal.

Von GENiALi | 29.10.2011 21:11

Ich betreue ein Projekt das ich eigentlich selber von A-Z aufgegleist habe. Eines meiner ersten Projekte. Dort habe ich auch versucht Begriffe ins Egnlische zu übersetzten. Mit verherenden Folgen auch für mich.Wenn man mal 3 Monate nichts mehr damit gemacht hat weiss ich oft nicht mehr welches Objekt jetzt genau gemeint ist. Ich habe mir so viel Ärger und Frust eingehandelt. Einfach nur weil es nicht mehr verstanden wurde. Bei den Kollegen das Selbe.Wenn ich es heute nochmals machen könnte würde ich für Domänenobjekte die Namen brauchen wie der Kunde. Man übersetzte mal "Nutzenkennzahl" oder "Nutzeneinschätzung" in EN und verstehe es dann in 3 Montan noch.Also würde ich es in DE machen. Egal ob noch EN drin ist. GetNutzenkennzahlById ist immer noch besser als so etwas in der Form "GetBenefitRatioById" oder "GetBenefitAssessmentById". Es verursacht einfach zu viele Probleme.