英語以外のドメインでのプログラミングとユビキタス言語（DDD）
このテーマに密接に関連する質問がすでにここにあることは知っていますが、ユビキタス言語を出発点とする質問はないので、この質問を正当化すると思います。 知らない人のために：ユビキタス言語とは、翻訳の問題や誤解による矛盾や誤解を避けるために、開発者とドメインの専門家の間で等しく使用される（話し言葉と書き言葉の両方の）言語を定義する概念です。同じ用語がコード、チームメンバー間の会話、機能仕様などに表示されます。 だから、私が疑問に思ったのは、英語以外のドメインでユビキタス言語に対処する方法です。 個人的には、コメントを含むが、もちろん定数とリソースを除く、完全に英語でプログラミングコードを書くことを強く推奨します。 ただし、英語以外のドメインでは、次のいずれかを決定する必要があります。 ドメインの自然言語でユビキタス言語を反映するコードを記述します。 ユビキタス言語を英語に翻訳し、ドメインの自然言語でのコミュニケーションを停止します。 ユビキタス言語の英語への翻訳方法を定義するテーブルを定義します。 これらのオプションに基づく私の考えのいくつかを以下に示します。 1）混合言語コード、つまり英語以外の型/メンバー/変数名などを使用してコーディングすることに対して強い嫌悪感を持っています。ほとんどのプログラミング言語は英語をかなり「呼吸」し、ほとんどの技術文献、デザインパターン名なども英語です。したがって、ほとんどの場合、英語以外の言語で完全にコードを記述する方法はないため、いずれにしても混合言語になります。 2）これにより、ドメインの専門家は、ULに相当する英語で考えて話し始めるように強制されます。 3）この場合、開発者は母国語でドメインエキスパートと通信し、開発者は互いに英語で通信します。最も重要なのは、ULの英語翻訳を使用してコードを書くことです。 私は最初のオプションに行きたくないと確信しており、オプション3はオプション2よりも優れていると思います。他のオプションがありませんか？ 更新 約1年後の今日、この問題を日常的に扱ってきたので、オプション3がうまく機能したと言わざるを得ません。 最初に恐れていたほど退屈ではなく、クライアントと話すこともリアルタイムで翻訳することも問題ではありませんでした。 私の経験に基づいて、次の利点があることもわかりました。 ULを翻訳すると、特に用語の翻訳方法がわからず、辞書などを調べ始める必要がある場合に、ULおよびドメイン自体の定義にさらに注意を払うことになります。何回か。 英語の知識をより深めるのに役立ちます。 明らかに、あなたのコードは、わいせつな気分になるのではなく、見るのがはるかに楽しいです。