英語以外のドメインでのプログラミングとユビキタス言語（DDD）
この主題に密接に関連する質問がすでにここにいくつかあることは知っていますが、どれも ユビキタス言語 を出発点としないので、この質問を正当化すると思います。
知らない人のために：ユビキタス言語は、翻訳の問題や誤解による矛盾や誤解を避けるために、開発者とドメインの専門家の間で等しく使用される（話し言葉と書き言葉の両方）言語を定義する概念です。同じ用語がコード、チームメンバー間の会話、機能仕様などに表示されます。
だから、私が疑問に思っていたのは、英語以外のドメインでユビキタス言語をどのように扱うかです。
個人的には、コメントを含め、もちろん定数とリソースを除いて、プログラミングコードを完全に英語で書くことを強く推奨します。
ただし、英語以外のドメインでは、次のいずれかの決定を迫られます。
- ドメインの自然言語でユビキタス言語を反映するコードを記述します。
- ユビキタス言語を英語に翻訳し、ドメインの自然言語でのコミュニケーションを停止します。
- ユビキタス言語が英語にどのように翻訳されるかを定義するテーブルを定義します。
これらのオプションに基づく私の考えの一部を以下に示します。
1）英語以外のタイプ/メンバー/変数名などを使用してコーディングしている、混合言語コードに対する強い嫌悪感があります。ほとんどのプログラミング言語は英語を大いに「呼吸」し、ほとんどの技術文献、設計パターン名なども同様に英語です。したがって、ほとんどの場合、完全に英語以外の言語でコードを記述する方法がないため、結局、混合言語になってしまいます。
2）これにより、ドメインの専門家は、ULに相当する英語で考え、話し始めるように強いられます。これは、おそらく自然に伝わるものではないため、コミュニケーションを大幅に妨げます。
3）この場合、開発者は母国語でドメインエキスパートと通信しますが、開発者は英語で互いに通信します。最も重要なのは、ULの英語翻訳を使用してコードを記述することです。
私は最初のオプションに行きたくないと確信しており、オプション3はオプション2よりもはるかに優れていると思います。どう思いますか？他のオプションがありませんか？
[〜＃〜]更新[〜＃〜]
今日、約1年後、この問題を日常的に扱ってきたので、オプション3はかなりうまく機能していると言わざるを得ません。
それは私が最初に恐れていたほど面倒ではなく、クライアントと話をしながらリアルタイムで翻訳することも問題ではありませんでした。
また、私の経験から、次の利点が正しいことがわかりました。
- ULを翻訳すると、特に用語の翻訳方法がわからず、辞書などを調べなければならない場合に、ULとドメイン自体の定義にも注意を向けることができます。これにより、ドメインモデリングの決定を再考する必要が生じました。何回か。
- 英語の知識を深めるのに役立ちます。
- 明らかに、あなたのコードは、気の遠くなるようなわいせつなものになるよりも、見るほうがずっと楽しいです。
私はこの問題に頻繁に直面しており、私の意見では、「すべてのシナリオに有効な単一の回答はありません」と私は考えています。
ただし、ユビキタス言語はそれ自体が目標ではないことに注意してください。これは、チームとドメインエキスパート間のコミュニケーションを強化し、実装されたモデルの概念的な一貫性をコード、テスト、会話で実施するためのツールです。
ULを明確に話すことができれば、正しい方向に進んでいます。あなたとあなたの仲間がコードから会話へ、または概念から概念へと継続的に翻訳しているなら、あなたはおそらく順調ではありません。
実際には、すべてのドメインが等しいわけではなく、ドメインの専門家でもありません。とにかく、いくつかのドメインには英語の用語がたくさんあり（たとえば、技術主導のドメイン）、完全な英語の選択を選択するのが妥当なように思えます。ただし、一部の文化はこの選択に影響を与える可能性があり（フランス語が頭に浮かびます）、英語の用語の普及は国によって異なります。他のいくつかのドメイン（1つを名づけると法的）では、いくつかの用語を翻訳する方法がありません。または翻訳すると、ドメインエキスパートが会話を理解するのが非常に困難になります。
一般的に、ドメインエキスパートの意見に関心があります。だから私たちは彼らのために物事を簡単にしたいです。それ以外の場合は、UMLクラスを取得して図を読み取るだけです（これは冗談でした）。したがって、ここでの唯一の実際の推奨事項は、「ドメインエキスパートの動作に注意を払う」ことです。彼らが会話に従事していて、会話がスムーズに進行している場合は、おそらく順調に進んでいますthat language 。チームで少し余分な作業が発生する可能性がありますが、それで問題ありません。開発者として、私たちはコンテキスト内で特定の意味を持つ単語を学ぶようにある程度訓練されています。
奇妙なことに、この質問には常に、すべてのコードが1つの言語を話す必要があるという仮定が伴います。それも挑戦されるかもしれません。私は母国語ではないので、外国語の知識は平坦ではありません。名前、姓、車について話すと頭が速くなりますzipcodeについて話すときにいくつかの詳細を見逃し、-loanについて話すときに遅くなり、-mortgageについて話すときに確かな説明を求めます。
したがって、ここでも、主要な会話の流れを作り、ドメインエキスパートからの情報とフィードバックを最も多く提供する最適な組み合わせを選択してください。
私は通常、他の言語での翻訳があっても、特定の専門用語を言語中立と見なします。
たとえば、ドイツ語でのコーディングについて話すときは、ドイツ語の同等の語彙があっても、ドイツ語の単語であるかのように英語の技術用語を使用しています。
あなたの場合、私は反対をします。何世紀にもわたって外国語がインポートされてきたのと同じように、特定の技術用語を母国語から英語にインポートします。文法的に英語の単語のように振る舞わせる。最初は変な感じがしますが、慣れるでしょう。
私は最近、スイスのDDDプロジェクトに取り組みました。ドメインは税金でした（具体的には、VATと別の種類の税金...英語に簡単に変換できない...）。
彼らは最初のオプション、ドイツ語のULを選択しました。ドイツ語のコードでも使用されています。
このプロジェクトに取り組む前は、混合言語コードに対するあなたとまったく同じ嫌悪感がありました。私は（まだ）すべてを英語で話すのが好きですが、私はネイティブの英語を話す人ではありません。私はドイツ語のネイティブスピーカーでもありません。そのため、コードベースを探索し始めたとき、私は恐怖に襲われました。
そのプロジェクトに1年取り組んだ後、この場合は正しい決定だったと思います（フランス語またはイタリア語、その他のスイスの公用語を使用することもできますが、プロジェクトの俳優の大半はネイティブドイツ語でした）スピーカー）。
ドメインの特定の用語の多くは、意味のある方法で実際に英語に翻訳できませんでした。チームの他のメンバーとコミュニケーションをとるために、私はとにかくドイツ語を学ばなければなりませんでした。とにかく薄い空気から発明されたであろう、英語の翻訳も学ぶ必要があるのは面倒だったでしょう。
ですから、本当にドメインに依存していると思います。一部のドメインは英語に翻訳するのが本当に難しく、あまり意味がありません。
それはおそらくネイティブ言語にも依存します。ドイツ語は、英語とほぼ同じ方法、特に同じ順序で単語を作成できる言語です。たとえば、税申告はSteuerdeklarationになります。驚くほど違いはありません。
たとえば、フランス語で同等のクラス名を作成する方法がわからない。たとえば、自然な用語が「宣言d'impôts」で、逆の順序と余分な前置詞が真ん中にあるとしたら...簡単な例。誰かがラテン語（フランス語、スペイン語、イタリア語、ポルトガル語...）でそのようなネーミングを経験したことがあれば、本当に興味があります。
もう1つの課題は複数形でしたが、ドイツ語では単数形と区別がつかない場合があります（英語では、ほとんどの場合、末尾にsが付きます）。
アクセント記号付きの文字は問題ありませんでした。ドイツ語では、すべてアクセント記号なしの対応物があるためです（ü-> eなど）。それは、フランス人がより問題になる別のポイントです...
ほとんどのプログラミング言語は「呼吸する」英語コメントに同意します。コメントは常に多言語開発の取り組みで問題になります
通常、プログラミングチームの言語でULを取得します
私たちが過去に行ったことは、ドメイントピックをよりよく表す新しい単語を作成することです。フランス語/英語のプロジェクトでは、ほとんどが英語ベースであるがフランス語のフレーバーを備えた構成された単語（多くの英語の単語はフランス語であるのでそれほど難しくありません）ですが、これはあらゆる言語の組み合わせに適用できます
例えば.
「数量ボア」
英語では「木材の量」または「木材の量」であり、フランス語では「quantitéde bois」であるため、両方の話者にとって十分に近いです。これにより、各スピーカーが学習する必要のある新しい単語の量が減ります。
ドメインULの大きさはどれくらいですか？これが問題になります。キーフレーズが100未満の場合は、ハイブリッドメイクアップスタイルの言語を使用できます。大きい場合は、開発者の主流の言語を通常より厳格に処理する必要があるため、こだわります。
必要に応じて誰もが参照できるようにwiki辞書/シソーラスを公開して、理解の言い訳がないようにする