英語以外のドメインでのプログラミングとユビキタス言語（DDD）

このテーマに密接に関連する質問がすでにここにあることは知っていますが、ユビキタス言語を出発点とする質問はないので、この質問を正当化すると思います。

知らない人のために：ユビキタス言語とは、翻訳の問題や誤解による矛盾や誤解を避けるために、開発者とドメインの専門家の間で等しく使用される（話し言葉と書き言葉の両方の）言語を定義する概念です。同じ用語がコード、チームメンバー間の会話、機能仕様などに表示されます。

だから、私が疑問に思ったのは、英語以外のドメインでユビキタス言語に対処する方法です。

個人的には、コメントを含むが、もちろん定数とリソースを除く、完全に英語でプログラミングコードを書くことを強く推奨します。

ただし、英語以外のドメインでは、次のいずれかを決定する必要があります。

1. ドメインの自然言語でユビキタス言語を反映するコードを記述します。
2. ユビキタス言語を英語に翻訳し、ドメインの自然言語でのコミュニケーションを停止します。
3. ユビキタス言語の英語への翻訳方法を定義するテーブルを定義します。

これらのオプションに基づく私の考えのいくつかを以下に示します。

1）混合言語コード、つまり英語以外の型/メンバー/変数名などを使用してコーディングすることに対して強い嫌悪感を持っています。ほとんどのプログラミング言語は英語をかなり「呼吸」し、ほとんどの技術文献、デザインパターン名なども英語です。したがって、ほとんどの場合、英語以外の言語で完全にコードを記述する方法はないため、いずれにしても混合言語になります。

2）これにより、ドメインの専門家は、ULに相当する英語で考えて話し始めるように強制されます。

3）この場合、開発者は母国語でドメインエキスパートと通信し、開発者は互いに英語で通信します。最も重要なのは、ULの英語翻訳を使用してコードを書くことです。

私は最初のオプションに行きたくないと確信しており、オプション3はオプション2よりも優れていると思います。他のオプションがありませんか？

更新

約1年後の今日、この問題を日常的に扱ってきたので、オプション3がうまく機能したと言わざるを得ません。

最初に恐れていたほど退屈ではなく、クライアントと話すこともリアルタイムで翻訳することも問題ではありませんでした。

私の経験に基づいて、次の利点があることもわかりました。

• ULを翻訳すると、特に用語の翻訳方法がわからず、辞書などを調べ始める必要がある場合に、ULおよびドメイン自体の定義にさらに注意を払うことになります。何回か。
• 英語の知識をより深めるのに役立ちます。
• 明らかに、あなたのコードは、わいせつな気分になるのではなく、見るのがはるかに楽しいです。

私はこの問題に頻繁に直面しており、私の意見では、答えは「すべてのシナリオに有効な単一の答えはありません」です。

しかし、ユビキタス言語はそれ自体が目標ではないことに留意してください。これは、チームとドメインエキスパート間のコミュニケーションを強化し、実装されたモデルの概念的な一貫性をコード、テスト、および会話で実施するためのツールです。

ULを明確に話せるなら、あなたは正しい道を歩んでいます。あなたとあなたの仲間がコードから会話へ、または概念から概念へと絶えず翻訳しているなら、あなたはおそらく軌道に乗っていないでしょう。

実際には、すべてのドメインが同等というわけではなく、ドメインの専門家であるわけでもありません。とにかく多くの英語の用語を持っているドメイン（たとえば、技術主導のドメイン）があり、完全な英語の選択を選択するのが妥当と思われます。ただし、一部の文化はこの選択に影響を与える可能性があり（フランス語が思い浮かびます）、英語の用語の普及は国によって異なります。他の一部のドメイン（法律上、名前を付けると）では、一部の用語を翻訳する方法がありません。または、翻訳すると、Domain Expertが会話を追跡するのが非常に難しくなります。

一般的に、ドメインエキスパートの発言に関心があります。そこで、彼らにとって物事を簡単にしたいのです。それ以外の場合は、UMLクラスを取得して、図を読むだけです（冗談でした）。したがって、ここでの唯一の本当の推奨事項は、「ドメインエキスパートの動作に注意を払う」ことです。会話に参加して会話がスムーズに進む場合、おそらくその言語を維持します。チームに少し余分な作業が発生する可能性がありますが、それで問題ありません。開発者として、コンテキスト内で特定の意味を持つ単語を学習するようにある程度訓練されています。

奇妙なことに、この質問には常に、すべてのコードが1つの言語を話す必要があるという仮定が伴います。それも挑戦されるかもしれません。私はネイティブ英語ではなく、外国語の知識は平坦ではありません。名前、姓、車などについて話すと頭が速くなり、郵便番号について話すと一部の詳細を見逃し、ローンについて話すと遅くなり、間違いなく尋ねます住宅ローンについて話すときの安心できる説明を求めて。

そのため、ここでも重要な会話が流れ、ドメインエキスパートからの情報とフィードバックを最大限に提供する最適な組み合わせを選択してください。

私は通常、他の言語の翻訳があっても、特定の専門用語を言語に中立であると考えています。

たとえば、ドイツ語でのコーディングについて話すときは、ドイツ語に相当する用語があっても、英語の技術用語をドイツ語の単語として使用します。

あなたの場合、私は反対を行います。外国語が何世紀にもわたってインポートされているように、母国語から英語に特定の技術用語をインポートします。それらを文法的に英語の単語のように動作させます。最初は奇妙に感じますが、それに慣れるでしょう。

私は、ほとんどのプログラミング言語が「呼吸する」英語のコメントに同意します。これは常に多言語開発の取り組みで問題になります

通常、私はあなたのプログラミングチームの言語でULを取得します

過去に行ったことは、ドメイントピックをよりよく表現する新しい単語を作成することです。フランス語/英語プロジェクトでは、ほとんどが英語ベースですが、フランス語の味を備えた構成された単語（とにかく多くの英語の単語がフランス語であるほど難しくはありません）が、これはあらゆる言語の組み合わせに適用できます

例えば

「数量ボア」

英語では「Amount of wood」または「quantity of wood」、フランス語では「quantitéde bois」であるため、両方の話者にとって十分に近い。これにより、各スピーカーが学習しなければならない新しい単語の量が減るはずです。

ドメインULの大きさは？これが問題になります。キーフレーズが100未満の場合、ハイブリッドメイクアップスタイル言語を使用できます。大きい場合は、開発者の主な言語を使用します。

すべての人が必要に応じて参照できるように、ウィキ辞書/シソーラスを公開し、理解の言い訳がないようにします

私は最近、スイスでDDDプロジェクトに取り組みました。ドメインは税金でした（具体的にはVATと別の種類の税...これは英語に簡単に翻訳できません...）。

彼らは最初のオプションを選択しました：ドイツ語のUL、ドイツ語のコードでも使用されています。

このプロジェクトに取り組む前は、混合言語コードについてあなたとまったく同じ嫌悪感を抱いていました。私は英語を母国語とする人ではありませんが、すべてを英語で話したいです。私はドイツ語のネイティブスピーカーでもありません。そのため、コードベースの調査を始めたとき、私はぞっとしました。

そのプロジェクトに取り組んで1年後、私はそれがこのケースで正しい決定だと思うことを認めなければなりませんスピーカー）。

ドメインの特定の用語の多くは、実際には意味のある方法で英語に翻訳できませんでした。チームの他のメンバーとコミュニケーションをとるために、とにかくドイツ語の用語を学ばなければなりませんでした。英語の翻訳も学ばなければならないのは面倒だったでしょう。それはとにかく薄い空気から発明されたでしょう。

ですから、それは本当にドメインに依存していると思います。一部のドメインは、英語への翻訳が非常に難しく、あまり意味がありません。

おそらく母国語にも依存します。ドイツ語は、英語とほぼ同じ方法で、特に同じ順序で単語を構成できる言語です。たとえば、税務申告はSteuerdeklarationになります。驚くほど違いはありません。

たとえば、フランス語で同等のクラス名を作成する方法がわかりません。たとえば、「déclarationd'impôts」という自然用語は、逆の順序で、中央に余分な前置詞があります。簡単な例。ラテン語（フランス語、スペイン語、イタリア語、ポルトガル語など）でそのようなネーミングの経験がある人がいたら、本当に興味があります！

別の課題は複数形でした。ドイツ語では単数形と区別できない場合があります（英語ではほとんどの場合末尾にsがあります）。

ドイツ語ではすべてアクセント記号のない同等の文字（ü- > ueなど）があるため、アクセント記号付きの文字はOK でした。それはフランス人がより問題になる別のポイントです...