ビジネスクラスにはどの言語で名前を付ける必要がありますか？

この質問でベストプラクティスを要求しています。これは、顧客会社が英語以外の母国語を厳密に持っている場合にのみ問題になると思います。

顧客が主に非常にドメイン固有の（たとえば、ドイツ語）表現を多く持っており、ドメイン固有ではないいくつかの名前が混在している場合。コードコメントの言語、クラス/メソッド/変数名は英語です。すべてのドメイン固有の名前を翻訳しますか？

私はドイツで働いていますが、英語を選びたいです。

たとえば、「DATEV」（ドイツの請求書/請求書作成ソフトウェア）へのモジュールの作成など、ドメイン固有のことです。ドイツ語の名前を使用します。「Referenzbuchungsnummer」（ReferenceBookingNum？）や「Sachkontenlaenge」（..？）など、ドイツ語の一部の単語は正しく翻訳できません。また、ドメイン固有のことはメンテナンスの恐怖で終わると思います。ReferenceBookingNumが「Referenzbuchungsnummer」に関連することを覚えているかもしれませんが、同僚についてはどうでしょうか。ドキュメントが存在する場合、ネーミングに関する内部ドキュメントを調査する必要があります。適切な名前がなければ、彼らはモジュールにあまり馴染みがありません。他のすべての開発者もドイツ人である場合、それは不必要な複雑さです。しかし、「CakeFactory」は「KeksFabrik」よりもはるかに優れています;）

だからそれはすべて依存しています。

ノルウェーの会社で働いているノルウェー人なので、オブジェクトに英語で名前を付けます。もちろん、一部の単語または概念には対応する英語がない場合があり、その場合、意味のない不適切な置換またはリテラル翻訳の代わりにネイティブの単語が使用される可能性があると主張できます。もちろん、これらの問題の多くは、私たちの一部がより良い語彙を持っているべきであるという事実かもしれないので、私は通常、同僚に良い英語名を考えられないかどうか尋ねます:)

一部のスタッフはノルウェー人ではないため、英語で書くことは彼らにとって有益です。ヨーロッパのほとんどからプログラマーを雇えることは経済に良いので、私の会社もそれから恩恵を受けています。

ところで、私はエルメスのソースを一度読んだことを覚えています（ebXML b2b実装）。彼らが北京語で書いたりコメントしたりしたら、苦労したでしょう。

英語はITドメインの共通語であるため、ソースコードを別の言語に制限すると、英語の開発が人為的に妨げられると考えています。最初に、特定の言語を話す人々に貢献できる人々のプールを制限します。ローカルサイトではなくスタック交換で尋ねたのと同じ理由。

また、あなたは貢献がどこから来てどこへ行くのか分かりません。サイトのサンプルを使用する場合、それを翻訳しますか？製品が他の国のクライアントから使用されるように拡張された場合はどうなりますか？請負業者を雇う必要がある場合/少し外注しますか？なぜ1つのプールに制限し、世界中から最もフィットしないのですか？

他の言語に簡単にマッピングされないドメイン固有の構造、または既存のコードベースが維持されている場合は問題ないと想定できます。

私の最後のプロジェクト目標は、担保と住宅ローンのビジネス領域をモデル化することでした。開発者と私たちが働いた会社はすべてポーランド出身です。ドメイン駆動設計の原則に従ってソフトウェアを構築しました。すべての事業体にポーランド語の名前を使用しましたが、非常に良い選択だったと思います。このアプローチのおかげで、コミュニケーションの問題を回避できたと思います。ビジネス分野は、英語の翻訳はもちろんのこと、ポーランド語でも知らない多くの用語で構成されていました。ラテン文字のみを使用し、すべての技術クラスは英語で命名されました。

一般に、単一の言語で記述されたソースコードを読む方が簡単です。ほとんどのプログラミング言語では、これは英語で書く必要があることを意味します。

とはいえ、英語に簡単に翻訳できないドメインの概念には大きな問題があります。典型的な例は、社会が個人に与える一意の識別子です。米国では、最も近い概念は社会保障番号ですが、正確なマッピングではありません。通常、名前と電話番号は非常によくマッピングされます。

私は通常、正確なマッピングが英語にすぐに利用できないときは常にドメイン用語を保持する必要があると信じていますが、それらだけは-英語で残りを保持します。KommuneImplのような異常な識別子になりますが、ドメインを知っている人にはすぐに意味があります。

オープンソース/国際コミュニティ型プロジェクト

オープンソースおよび国際コミュニティプロジェクトの共通言語は英語です。適切な例として、Stack Exchangeサイトの言語は英語です。最も広範なアクセシビリティを実現するには、すべてのコードおよびオブジェクト名に英語を使用する必要があります。

商業プロジェクト

ほとんどの国際的なソフトウェア会社は、コードを英語で書くことを義務付けています。それは最大の共通分母なので、一貫性を作り出す手段として英語を使用することは理にかなっています。

多くの地域のソフトウェア会社は母国語で書いています。すべてがこのアプローチに従うわけではありませんが、彼らの観点からは理にかなっています-彼らはすべての開発者に共通言語を使用しています。

ビジネスオブジェクトの命名

オブジェクトの命名には、チームのコーディング言語を使用する必要があります。
優先事項は、開発者がオブジェクトとプロジェクト要件に関して相互に通信できるようにすることです。チームがフランス語で書く場合、ビジネスオブジェクトはフランス語で命名する必要があります。英語でコーディングする場合は、オブジェクトに英語の名前を付けます。

クライアントがあなたのチームのコーディング言語以外の母国語を話すので、あなたの質問はしわを追加します。 チームのコーディング言語を使用してオブジェクトに名前を付ける必要があります。
ビジネスアナリストまたは開発者が特定のビジネスオブジェクトについてクライアントと通信する必要がある場合、オブジェクト名のコーディング言語からクライアント言語への必要に応じた翻訳が必要になる場合があります。私の経験から、特定のコードオブジェクトについてクライアントと話したことはほとんどないため、クライアント言語に戻す翻訳は実際には必要ありませんでした。

命名規則の唯一の例外は、オブジェクトの意図を把握するのに十分な簡潔な用語がオブジェクトにない場合です。IMO、これは本当にまれですが、発生する可能性があります。しかし実際には、話されている言語が特定の概念を表現するのと同じことです。「Facade」はもともとフランス語の用語ですが、コンセプトを表現するために英語で改作されており、一般的なデザインパターンです。「Schadenfreude」は、借用された用語のもう1つの良い例です。ただし、対応するパターンはないと思います。