Programmiersprache und Ubiquitous Language (DDD) in einer nicht-englischen Domäne

Ich weiß, dass es hier bereits einige Fragen gibt, die in engem Zusammenhang mit diesem Thema stehen, aber keine von ihnen geht von Ubiquitous Language aus, und ich denke, das rechtfertigt diese Frage.

Für diejenigen, die nicht wissen: Ubiquitous Language ist das Konzept der Definition einer (sowohl gesprochenen als auch geschriebenen) Sprache, die von Entwicklern und Domain-Experten gleichermaßen verwendet wird, um Inkonsistenzen und Missverständnisse aufgrund von Übersetzungsproblemen und Missverständnissen zu vermeiden. Dieselbe Terminologie wird im Code angezeigt, Gespräche zwischen Teammitgliedern, Funktionsspezifikationen und so weiter.

Ich habe mich also gefragt, wie ich mit Ubiquitous Language in nicht-englischen Domänen umgehen soll.

Persönlich bevorzuge ich es, Programmcode vollständig in Englisch zu schreiben, einschließlich Kommentaren, aber natürlich ohne Konstanten und Ressourcen.

In einer nicht-englischen Domäne bin ich jedoch gezwungen, eine Entscheidung zu treffen, um:

1. Schreiben Sie Code, der die Ubiquitous Language widerspiegelt, in der natürlichen Sprache der Domäne.
2. Übersetzen Sie die allgegenwärtige Sprache ins Englische und unterbrechen Sie die Kommunikation in der natürlichen Sprache der Domain.
3. Definieren Sie eine Tabelle, die definiert, wie die Ubiquitous Language in Englisch übersetzt wird.

Hier sind einige meiner Gedanken zu diesen Optionen:

1) Ich habe eine starke Abneigung gegen gemischtsprachigen Code, der unter Verwendung von Typ- / Element- / Variablennamen usw. codiert, die nicht englisch sind. Die meisten Programmiersprachen "atmen" weitgehend Englisch und die meiste Fachliteratur, Entwurfsmusternamen usw. sind auch in Englisch. Aus diesem Grund gibt es in den meisten Fällen keine Möglichkeit, Code vollständig in einer anderen Sprache als Englisch zu schreiben, sodass Sie ohnehin gemischte Sprachen haben.

2) Dies wird die Domain-Experten dazu zwingen, in der englischen Entsprechung des UL zu denken und zu sprechen, was für sie wahrscheinlich nicht selbstverständlich ist und daher die Kommunikation erheblich behindert.

3) In diesem Fall kommunizieren die Entwickler mit den Domain-Experten in ihrer Muttersprache, während die Entwickler auf Englisch miteinander kommunizieren. Vor allem schreiben sie Code mit der englischen Übersetzung des UL.

Ich bin sicher, dass ich mich nicht für die erste Option entscheiden möchte, und ich denke, Option 3 ist viel besser als Option 2. Was denken Sie? Vermisse ich andere Optionen?

AKTUALISIEREN

Heute, ungefähr ein Jahr später, nachdem ich mich täglich mit diesem Thema befasst habe, muss ich sagen, dass Option 3 für mich ziemlich gut funktioniert hat.

Es war nicht so langweilig, wie ich ursprünglich befürchtet hatte, und das Übersetzen in Echtzeit, während ich mit dem Kunden sprach, war auch kein Problem.

Aufgrund meiner Erfahrung habe ich auch die folgenden Vorteile für richtig befunden.

• Durch die Übersetzung des UL widmen Sie sich mehr der Definition des UL und sogar der Domäne selbst, insbesondere dann, wenn Sie nicht wissen, wie ein Begriff übersetzt werden soll, und Wörterbücher usw. durchsehen müssen. Dies hat mich sogar veranlasst, die Modellierungsentscheidungen für Domänen neu zu überdenken ein paar Male.
• Es hilft Ihnen dabei, Ihre Kenntnisse der englischen Sprache zu vertiefen.
• Offensichtlich ist Ihr Code viel angenehmer anzusehen, als eine irrsinnige Obszönität zu sein.

Ich habe mich häufig mit diesem Problem befasst, und meiner Meinung nach lautet die Antwort: "Es gibt keine einzige Antwort, die für alle Szenarien gültig ist."

Denken Sie jedoch daran, dass die allgegenwärtige Sprache an sich kein Ziel ist. Es ist ein Werkzeug, um die Kommunikation zwischen dem Team und den Domänenexperten zu stärken und die konzeptionelle Kohärenz des implementierten Modells in Code, Tests und Konversation zu erzwingen.

Wenn Sie UL eindeutig sprechen können, sind Sie auf dem richtigen Weg. Wenn Sie und Ihre Kollegen kontinuierlich von Code zu Konversation oder von Konzept zu Konzept übersetzen, sind Sie wahrscheinlich nicht auf dem richtigen Weg.

In der Praxis sind weder alle Domänen gleich, noch Domänenexperten. Einige Domains haben sowieso eine Menge englischer Terminologie (z. B. tech-getriebene Domains) und es klingt vernünftig, sich für eine vollständige englische Wahl zu entscheiden. Einige Kulturen könnten jedoch Einfluss auf diese Wahl haben (Französisch fällt mir ein), und die Verbreitung der englischen Terminologie ist von Land zu Land unterschiedlich. In einigen anderen Bereichen (Legal, um nur einen zu nennen) gibt es keine Möglichkeit, bestimmte Begriffe zu übersetzen. Oder das Übersetzen würde es Domain-Experten absolut schwerer machen, dem Gespräch zu folgen.

Im Allgemeinen interessiert uns mehr, was der Domain-Experte zu sagen hat. Deshalb wollen wir es ihnen leicht machen. Andernfalls könnten sie einfach eine UML-Klasse besuchen und unsere Diagramme lesen (das war ein Witz). Die einzige echte Empfehlung lautet hier: "Achten Sie auf das Verhalten von Domain-Experten". Wenn sie an der Unterhaltung beteiligt sind und die Unterhaltung reibungslos verläuft, sind Sie wahrscheinlich auf dem richtigen Weg. Behalten Sie diese Sprache bei. Es könnte ein wenig zusätzliche Arbeit für das Team bedeuten, aber das ist in Ordnung. Als Entwickler sind wir etwas geschult, um Wörter mit einer bestimmten Bedeutung in einem Kontext zu lernen.

Seltsamerweise geht diese Frage immer mit der Annahme einher, dass der gesamte Code eine Sprache sprechen muss. Das könnte auch in Frage gestellt werden. Ich bin kein Muttersprachler, und Fremdsprachenkenntnisse sind nicht einfach: Mein Gehirn geht schnell, wenn es um Namen , Nachnamen , Autos und dergleichen geht, es fehlen einige Details, wenn es um die Postleitzahl geht , es wird langsamer, wenn es um das Ausleihen geht, und ich frage definitiv für eine beruhigende Erklärung, wenn es um Hypothek geht .

Wählen Sie also erneut die beste Kombination aus, mit der die wichtigsten Konversationen ablaufen, und geben Sie dem Domain-Experten die größtmögliche Menge an Informationen und Feedback.

Ich betrachte in der Regel bestimmte Fachwörter als sprachneutral, auch wenn eine Übersetzung in die andere Sprache vorliegt.

Wenn ich zum Beispiel über Codierung auf Deutsch spreche, verwende ich das englische Fachvokabular immer noch so, als wären es deutsche Wörter, auch wenn es ein deutsches Äquivalent gibt.

In deinem Fall würde ich das Gegenteil tun. Importieren Sie bestimmte technische Wörter aus Ihrer Muttersprache ins Englische, genau wie Fremdwörter seit Jahrhunderten importiert werden. Lassen Sie sie sich grammatisch wie englische Wörter verhalten. Anfangs fühlt es sich komisch an, aber Sie werden sich daran gewöhnen.

Ich stimme dem Kommentar zu, dass die meisten Programmiersprachen Englisch "atmen" , was bei mehrsprachigen Entwicklungsbemühungen immer zu einem Problem wird

Normalerweise hätte ich die UL in der Sprache Ihres Programmierteams

Was wir in der Vergangenheit getan haben, ist, neue Wörter zu erfinden, die die Domain-Themen besser ausdrücken. Bei einem Französisch / Englisch-Projekt basierten die erfundenen Wörter hauptsächlich auf Englisch, aber mit französischem Flair (nicht zu schwer, da sowieso viele englische Wörter Französisch sind), aber dies könnte für jeden Sprachmix gelten

z.B

"Menge Bois"

Im Englischen ist "Holzmenge" oder "Holzmenge", im Französischen "Quantité de Bois", also nahe genug für beide Sprecher. Dies sollte die Anzahl der neuen Wörter reduzieren, die jeder Sprecher lernen muss

Wie groß ist Ihre Domain UL? Dies wird zum Problem. Wenn es weniger als 100 Schlüsselphrasen sind, können Sie eine hybride Stilsprache verwenden. Wenn größer, würde ich die vorherrschende Sprache der Entwickler beibehalten, da sie normalerweise intensiver damit umgehen müssen

Veröffentlichen Sie ein Wiki-Wörterbuch / einen Thesaurus, auf das / den jeder bei Bedarf verweisen kann, sodass es keine Entschuldigungen für das Verständnis gibt

Ich habe kürzlich an einem DDD-Projekt in der Schweiz gearbeitet, bei dem es um Steuern ging (insbesondere um Mehrwertsteuer und eine andere Art von Steuer ... die nicht einfach auf Englisch zu übersetzen ist ...).

Sie entschieden sich für die erste Option: UL in Deutsch, die auch im Code in Deutsch verwendet wird.

Bevor ich an diesem Projekt gearbeitet habe, hatte ich genau dieselbe Abneigung wie Sie für gemischten Sprachcode. Ich mag (noch) alles auf Englisch, obwohl ich kein englischer Muttersprachler bin. Ich bin auch kein deutscher Muttersprachler. Als ich mich mit der Codebasis befasste, war ich entsetzt.

Nachdem ich ein Jahr an diesem Projekt gearbeitet habe, muss ich zugeben, dass ich denke, dass es in diesem Fall die richtige Entscheidung war (wir hätten auch Französisch oder Italienisch, die anderen offiziellen Schweizer Sprachen, verwenden können, aber die Mehrheit der Akteure des Projekts waren deutsche Muttersprachler) Lautsprecher).

Viele der spezifischen Begriffe der Domain waren wirklich nicht sinnvoll ins Englische übersetzbar. Ich musste sowieso die deutschen Begriffe lernen, um mit dem Rest des Teams zu kommunizieren. Es wäre unordentlicher gewesen, auch englische Übersetzungen lernen zu müssen, die sowieso aus dem Nichts erfunden worden wären.

Ich denke, es hängt wirklich von der Domain ab. Einige Domains werden sehr schwer ins Englische zu übersetzen sein und es wird nicht viel Sinn machen.

Das hängt wahrscheinlich auch von der Muttersprache ab. Deutsch ist eine Sprache, in der Sie Wörter in etwa der gleichen Art und vor allem der gleichen Reihenfolge wie in Englisch verfassen können. Beispielsweise wäre eine Steuererklärung eine Steuerdeklaration . Nicht schockierend anders.

Ich weiß nicht, wie ich einen gleichwertigen Klassennamen auf Französisch machen würde, wenn der natürliche Begriff "Déclaration d'impôts" wäre, mit der entgegengesetzten Reihenfolge und einer zusätzlichen Präposition in der Mitte ... Und das ist gerecht ein einfaches Beispiel. Es würde mich sehr interessieren, wenn jemand Erfahrung mit dieser Art der Benennung in lateinischen Sprachen (Französisch, Spanisch, Italienisch, Portugiesisch ...) hat!

Eine weitere Herausforderung waren die Pluralformen, die auf Deutsch manchmal kaum vom Singular zu unterscheiden sind (während auf Englisch fast immer ein s am Ende steht).

Die akzentuierten Zeichen waren in Ordnung, da sie auf Deutsch alle ein nicht akzentuiertes Äquivalent haben ( ü -> ue und so weiter). Es ist ein weiterer Punkt, an dem die Franzosen problematischer wären ...