回答:
内部名と外部名の不一致は間違いなく悪臭を放ちます。リンツウィンドが指摘するように、同音異義語と同義語の匂いは最悪です。
あなたが答える必要がある本当の質問は、次のとおりです。変更を行う際のコスト/利益のトレードオフは何ですか？
変更しないことのコストは、新しいチームメンバーにとって学習曲線が急勾配であり、将来のバグの可能性が高くなることです。変更のコストは、関係する明らかな時間、プロジェクトのベテランユーザー向けの新しい学習曲線、および新しいバグの可能性です。
比較的多数の新しいチームメンバーがいることを期待している場合は、変更を行う方が理にかなっています。離職を期待していない場合、現在のチームは混乱する傾向がなく、チームは現状に満足しているので、名前を変更するのは本当に意味がありません。
コードが長期間存続することが予想され、新しい開発者が作業する場合は、変更を加えます。
新しい開発者がプロジェクトに参加して、エンティティの名前が誤解を招きやすいことを見つけることは、非常に混乱し、時間がかかります。
また、...の有効な引数もあります。壊れていない場合は、修正しないでください。
2番目の質問に関して、公開されている研究やベストプラクティスについては知りません。最初の質問については、「内部」と「外部」の名前が異なる場合がある類似の長寿命製品での個人的な経験からいくつかの観察を提供できます。
私が本当に修正したい名前は「同音異義語」です。そこでは、1つの名前が内部的にも外部的にもさまざまなことに使用されます。これは、特に2つのことが完全に異なっていない場合（コンテキストが曖昧さを解消するのに役立つ場合）、非常に混乱しやすいものです。私の個人的な経験におけるその1つの（抽象化された）例は、内部的にあなたがFoo複数のコレクションであるようなものを持っているところFooEntityです。外部では、後者のみが表示され、「Foo」と呼ばれます。カスタマーマニュアルが複数の「Foo」について話しているとき、それが実際には複数のFooEntity（1つのFoo）を意味することを理解するためにしばらくかかりました。
第二に、何らかの外部名が内部的に使用されている「類義語」を修正したいと思います。変数名、メソッド/関数名の一部などのように。これは、開発者が顧客要件の説明から何かを直接実装し、名前を「翻訳」するのを忘れた場合によく起こります。他の開発者がたまたまそのコードの一部をコピー/貼り付けして新しいコードのテンプレートとして使用するなど、「間違った」名前も広まる傾向があります。これらの同義語はそれほど複雑ではありませんが、コードへの参照を検索する場合Bar、一部の部分がQux、したがって、2回検索する必要があります。（ただし、動的型付けされた言語では、型の名前ではなく変数/関数/ ...の名前の一部を検索する必要があるため、静的型言語よりも悪い場合があります。）「類義語の逆の場合内部名が外部で使用されている場合：これは、カスタマーサポートの従業員などは通常内部名をあまり知らないため、それほど頻繁には発生しない傾向がありますが、実際に発生すると顧客を混乱させます。
少なくとも上記の2つの状況を回避または修正できる場合、すべての内部名を外部名と同じにする必要があるかどうかはわかりません。そもそも外部名が内部名と異なる場合に内部名も変更されなかったのには、おそらく正当な理由があります。私の個人的な経験では、その正当な理由は、製品の古いバージョンをサポートする必要があることです。多くのコードを変更する必要がある場合、名前のクリーンアップ前のバージョンから最新バージョンにバグ修正をマージするのが難しくなる可能性があります。
そのかなり一般的な問題。私が取り組んだ多くのプロジェクトでは、製品名の代わりにコード名を使用し（その時点では決定されていなかったかもしれません）、ユーザーに表示されるものとは大幅に異なる用語をコードで使用します。コードの大規模な再利用を受けている場合、または問題を引き起こす特定の何かがある場合を除き、おそらくそのままにしておきます。リンゴのカートをひっくり返すのに使用しません。また、5年後にはこれ以上の変化はないだろうか？そして、名前の変更をもう一度行う必要があります。そして、それはまた、あなたが持っているかもしれない別々のコードドキュメント（公開されたAPI）にも影響します。これは、印刷（ハードコピー）する場合、特に費用のかかる問題になる可能性があります。
多くの場合、「マーケティング」エンティティは内部エンティティと正確に対応していないことがわかります。そのような場合、異なる抽象化レベルでエンティティを導入する方が理にかなっています。これにより、用語の違いが重要なポイントになります。
たとえば、階層を表すモデルがあります。階層の各レベルには、実世界の関係をモデル化するために階層がどのように使用されるかに基づいて関連する用語がありますが、内部的には階層のレベルごとに動作に違いはありません。用語は基本的に階層内のそのレベルの単なる名前であるため、ツリー内の特定のノードについては、名前は単にノードが何であるかを説明しています。特定の動作を規定するものではありません。
また、ツリーはマルチルートであるため、親のないノードがいくつかあります。概念的にはルートが存在し（本質的にユニバースを表します）、モデルにそれを含めると、多くの操作がはるかに単純になりますが、「マーケティング用語」はありません。
もちろん、システム内の異なるコンポーネントは異なる用語を使用しています。それらは異なるチームによって異なる時期に開発されたものであり、私たちはそれらすべてを管理することはできません。実際、ある時点で誰かが1つのコンポーネントのレベルを追加または削除したため、他のレベルは相互にシフトされます。同じ3つのレベルは、1つのコンポーネントではA、B、およびCで表されますが、別のコンポーネントではB、C、およびDとして表されます。
抽象化の一歩を踏み出し、すべてを「ノード」または同様に汎用的なものとして単純にモデリングすることで、これらの種類のモデルの推論がはるかに容易になります。各ノードは、その「マーケティング用語」が何であるかを知っており、特定のマーケティング用語を表すタイプは、その用語が各コンテキストで何を意味するかを知ることができます。