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

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

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.

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üße
Stefan

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

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

Frage an die English-Befürworter: wie reden dann die Entwickler untereinander? So: "In der Implementierung des ShoppingBasket ist noch ein Fehler. Die Colors der Products werden falsch dargestellt"?

Und wie diskutieren wir dann mit dem Kunden? Auf english? Auf deutsch mit englishen Fachwörtern? Komplett auf Deutsch?

Der Kerngedanke der Ubiquitous Language im Sinne von Eric Evans ist, dass _keine_ Übersetzung notwendig ist. Denn genau diese führt zu Misverständnissen.

Eric spricht sich übrigens für eine deutsche ubiquitous language aus, ich habe mich darüber mit ihm länger unterhalten.


Grüße
Stefan

Rein technische Klassen und Methoden wie beispielsweise Logger benenne ich weiterhin in English.

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?

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)
- KontaktpersonReader

usw.

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.

Hallo,

KundeMitId halte ich für keinen gelungenen Methodennamen - schlicht und ergreifend, weil das Verb fehlt (eben das "Get" oder ein Pendant dazu).

Außerdem drückt der Name nicht das aus, was die Methode macht: Du holst ja nicht einen Kunden mit einer ID (kann man auch Kunden ohne ID holen?), sondern einen Kunden an Hand seiner ID. Das ist ein Unterschied.

Natürlich redet man mit dem Kunden in dessen Sprache - das heißt, der Mehraufwand, zwischen der Sprache des Kunden und der projektinternen Sprache zu wechseln, liegt beim Entwickler, was ich persönlich aber für vertretbar halte.

Das Argument, wegen potenzieller internationaler Zusammenarbeit direkt auf englische Begriffe zu setzen, sei YAGNI, möchte ich so auch nicht unbedingt gelten lassen: Der Mehraufwand, statt in Deutsch in Englisch zu entwickeln ist auch mitsamt einem Glossar vernachlässigbar - der Mehrufwand, deutschen Code irgendwann ins englische zu übertragen, ist unverhältnismäßig hoch.

Von daher - ja, vielleicht brauche ich das Englische wirklich nie, aber es schadet nicht, es von vornherein zu machen.

Außerdem widerstrebt mir bei einer kompletten Eindeutschung noch ein weiterer Punkt: Die Frameworkklasse sind auch nicht auf Deutsch - das heißt, Mischmasch hat man auf jeden Fall. Und wo zieht man dann die Grenze? Ist ein Klasse mit einer statischen Methode, die Objekte erzeugt, eine XyzFactory oder eine XyzFabrik? Der eine schreibt dann KundeFactory, weil er sich an den etablierten Namen des Patterns halten will, der andere KundeFabrik, und der Dritte erfindet etwas gänzlich neues.

Dann doch lieber alles einheitlich.

Viele Grüße,


Golo

@Golo
Man muss den Bezeichner 'KundeMitId' im Kontext lesen. Dann wird klar, was das 'MitId' meint. Ferner ist aufgrund der Signatur klar, dass es sich um eine Funktion mit Rückgabewert handelt. Das kann dann nur eine Query sein. Wäre es ein Command, hätte die Methode keinen Rückgabewert. Ich verzichte daher auf das Get.
Also der Aufruf im Kontext:

var kunde = repository.KundeMitId(42);

Das "nur" der Entwickler zwischen Deutsch und Englisch übersetzen muss halte ich übrigens für die Crux an der Sache! Es ist schließlich am Ende "nur" der Entwickler, der den Code schreibt. Gerade deshalb sollte dieser Personenkreis möglichst wenig Übersetzung leisten, damit die Gefahr von Fehlinterpretationen sinkt.

Und nochmal meine Frage: wie unterhalten sich die Entwickler untereinander? "Im ShoppingBasket gibt es einen Fehler bei den Colors der Products?" Wohl kaum. Sie sprechen von "der Farbe der Produkte". Also sollten sie genau das im Code wiederfinden.

Grüße
Stefan

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.

@ Stefan: Damit untergräbt man aber sämtliche Regeln zur statischen Codeanalysis, was ich für konsistenten Code als ausgesprochen wichtig erachte.

Und natürlich spricht man als Entwickler von der "Farbe der Produkte", nun sind "Color" und "Product" aber auch relativ gängig. Wenn hingegen im Code die "BenefitRatioId" geschrieben steht, sagen die Entwickler das auch.

Du verwendest doch auch ansonsten für das meiste die englischen Begriffe, auch im gesprochenen, auch wenn Du die deutsche Übersetzung kennst, oder nicht?

Sagst Du wirklich "Einzelstück" statt "Singleton"? "Fabrik" statt "Factory"? "Identitätsnummer" statt "ID"? ...?

Ich finde, die ganze Diskussion geht viel zu sehr von der Domäne aus, und blendet alles weitere aus.

Ich gebe zu, dass es für die Kommunikation mit dem Kunden einfacher ist, wenn man nicht übersetzen muss. So weit ja.

Aber wenn das nach sich zieht, dass ich Probleme in internationalen Teams habe, dass statische Codeanalyse nicht mehr 100%ig greift, dass ich Mischmasch erhalte, dann stellt sich mir die Frage, ob der eine Vorteil all diese Nachteile wettmacht.

Und übrigens - egal, ob ich Englisch oder Deutsch verwende - einen zentralen Glossar brauche ich, wie Ilker ja bereits schrieb, so oder so. Denn ein domänenspezifischer Begriff wie "Nutzenkennzahl" oder eben "BenefitRatio" ist mir als Entwickler so oder so nicht geläufig.

Das sieht man doch bereits an solchen Kleinigkeiten wie, "Kennwort" oder "Passwort"? Wenn ich das in wirklich großen Projekten einheitlich haben will, brauche ich verbindliche Richtlinien. Ob darin dann steht: "Kennwort und Passwort heißen im Code 'Geheimnis'" oder "Kennwort und Passwort heißen im Code 'Secret'" ist dann IMHO zweitrangig.

Ich möchte mal so nebenbei eine Frage in den Raum werfen: Wieviel, wenn überhaupt etwas, bekommt der Kunde vom Code zu sehen? Interessiert den überhaupt, wie die Objekte namentlich deklariert sind? Der will nur seine Applikation so schnell und so gut wie möglich. Wie es unter der Haube tickt, interessiert doch nur Entwickler, oder? Ich denke, wir alle sind intelligent genug um englische Begriffe on the fly in die deutsche Sprache zu übersetzen, wenn wir mit Kunden in Dialog treten - genau so einfach, wie ihr ohne nachdenken zu müssen, gerade "on the fly" gedanklich übersetzt habt. :-)

Des weiteren muß ich Golo Recht geben, wenn er sagt daß die Framework-Klassen und Schlüsselwörter ja per se in englisch sind und das auch nicht änderbar ist. Zum Glück, man stelle sich nur einmal vor, aus einer WeakReference wird plötzlich ein SchwacherVerweis (siehe entspr. MSDN-Seite in DE) - greuslich!
Gruß Rainer

Einigen Vorsprechern möchte partiell recht geben, auch wenn ich den bisherigen Diskussionsverlauf als recht konservativ empfinde.

Grundsätzlich tendiere ich dazu eine Golo sehr ähnliche Meinung zu vertreten. Tendiere, da meine Meinungsbildung noch nicht abgeschlossen ist. Das Vermengen von deutschen Klassenbezeichnungen mit den englischen Framework Klassen
widerstrebt auch mir sehr. Was mir auch arge Bauchschmerzen bereitet ist, dass die Regeln zur Codeanalyse untergraben werden. Für mich ist dies fast das schwerwiegendste Argument.

Alles in allem handelt es sich um eine widersprüchliche Diskussion, aber genau deshalb halte ich die Diskussion für wichtig. Vielleicht geht sie zur Zeit in eine falsche Richtung. Dann muss sie eben gelenkt werden.
Vielleicht sollte diese Diskussion sogar mehr in die Breite getragen werden.

Wo GENiALi und Golo meines Erachtens völlig recht haben; einem Entwickler sind die feinen Nuancen in fachlichen Begrifflichkeiten nicht bekannt. Und auch wenn ich relativ gut und schnell Übersetzen kann, hört es bei mir, und mit Sicherheit den Meisten von uns, bei Fachtermini einfach auf. Oder wißt Ihr sofort wie "Bodenkulturdenkmal" übersetzt wird?! Aber wenn ich mir einen Begriff übersetzen muss, den ich vielleicht noch völlig richtig zuordnen kann, wie ergeht es einem Kollgegen oder auch Projektnachfolger? Vielleicht war die Übersetzung völlig falsch, in einem "inneren Glossar" aber korrekt zugeordnet.

Gut, das Glossar kann und soll mit dem Kunden entwickelt werden. Aber kann sich hier jemand die Eingangsdiskussion mit dem Kunden vorstellen, weshalb eine englische Übersetzung für "Landschaftspflegeobjekt" oder "Bodenkulturdenkmal" benötigt wird? Ein Aufwand, der nicht unterschätzt werden sollte. Da diese Variante aber dennoch durchaus praktikabel sein kann, tendiere ich auch dazu. Dann wird aber vielleicht doch ein internes Glossar erstellt und schon ist wieder eine potentielle Fehlerquelle eingebaut.

Genau das ist doch das eigentliche Problem, weshalb Begriffe in der domänenspezifischen Sprache genutzt werden sollten. Aufgrund der Kommunikation und möglichen Problemen die damit verbunden sind. Natürlich sieht der Kunde den Quellcode in der Regel nicht. Er ist ihm meist sogar relativ egal, solange das Ergebnis das tut, was er sich davon verspricht. Aber darum geht es auch gar nicht: Es geht um Kommunikation - mit dem Kunden - "bridging the communcation gap".

Zwei Fragen möchte ich aber gerne noch einmal in den Raum stellen:
Wie verfahrt Ihr, wenn der Kunde explizit deutschen Quellcode fordert? Gerade im behördlichen Kontext ist dies keine Seltenheit. Einfach nicht machen, der Kunde sieht es ja eh nicht?
Ist der Logger wirklich ein Logger und außerhalb der Domäne? In der Regel hat der Kunde doch sehr klare Anforderungen an eine "Protokollierung"?

Die eigentliche Frage aber, die mich in dieser Diskussion wirklich beschäftigt, lautet:
Wäre es sinnvoll möglich deutsch bennante Klassen zu schreiben und zu nutzen und unter welchen Bedingungen?
Denn die Eingangsfrage scheint tatsächlich mit "Ja" beantwortet werden zu müssen...