エンティティ抽象化レベルの最適な数はいくつですか？
あいまいな質問については申し訳ありません。別の処方を提案してください。とにかくここに質問の核があります：
エンティティ/リソースまたはそれを呼び出したいものを表すクラスはいくつありますか？ serオブジェクトの例を見てみましょう。
リポジトリレベルでUserEntityがDBエンティティ（ORMによって自動生成されることもあります）にマップされ、サービスレベルUserDTOにマップされ、次にUserオブジェクトにマップされてAPIまたはビューレイヤーから返されることがよくあります。 CRMUser、ShopUserなど、一部の人々がAPIオブジェクトごとに変換することを選択しているさまざまなAPIをプラグインする場合も、これはさらに複雑になります。
それらのすべてに同じ（または類似の）フィールドがあり、機能はありません。マッピングごとに、Converterクラスが必要であり、宗教インターフェイスに依存します。
つまり、結局はかなり複雑になります。
ここに従うべき意見やガイドラインはありますか？
適切な抽象化レベルを取得することは、古典的な「ゴルディロックス」シナリオです。
抽象化が少なすぎると、ORMの詳細が他のレイヤーに漏れたり、それらのレイヤー間に望ましくない結合が作成されたりする危険があります。
抽象化が多すぎると、コードが不必要に複雑になるリスクがあります。「*少し前に、XyzUserを使用していましたが、YzxUserになりました。なぜですか？！??」過度に抽象化されたコードのフローを追跡しようとすることは本当に難しいです。
だから、あなたは欲しいクマの赤ちゃん抽象化のボウル：少なすぎず、多すぎない;ちょうどいい。
しかし、その「ちょうどいい」レベルの抽象化とは何でしょうか。それは、基本的に、可能な限り少ない抽象化レベルであり、プロセスに望ましくない結合やリークのある抽象化を作成することはありません。アプリごとに異なるため、この数は決まっていません。代わりに、新しいレベルの抽象化を追加する必要があると感じるたびに、その価値があるかどうかを自問してください。デカップリングのメリットは、複雑さのデメリットを上回りますか？答えが「はい」であると感じた場合は、別のレベルの抽象化を追加し、答えが「いいえ」になった瞬間、おそらく「たぶん」であってもそうするのをやめます。後者はこのトピックの主観性を明らかにしますが、結合よりも複雑さを好む人もいれば、その逆を好む人もいます。したがって、毎回の回答は主観的ですが、あなた/あなたのチームがこの主観性と一致している限り、それは本当に重要ではありません。
抽象化レベルよりも重要なのは、漏れのない抽象化を持つことです。ほとんどのアプリケーションが最高の抽象化レベルを使用でき、それより低いレベルを調べなくても問題なく動作する場合は、その下にある抽象化レベルの数は（決して確認する必要はありません）重要ではありません。 2つの抽象化レベルがあり、ほとんどのアプリケーションが下位レベルを見て物事を正しく行う必要がある場合、2つのレベルは多すぎます。
特定の要件がない場合、答えはoneです。 DRY（自分自身を繰り返さないでください）およびKISS（簡単に保つ）のコア原則に従って、1つだけ必要な場合は複数のクラスを作成しないでください多くのアプリケーションでは、単一のUserクラスが最適な数になります。
ただし、特定の要件があり、それ以上の要件がある場合もあります。たとえば、APIを公開し、そのデータモデルをビジネスロジックから切り離したい場合などです。ここでの経験則は、クラスがまったく同じである場合、おそらく複数は必要ないということです。ただし、クラスがわずかに異なる概念を表し、異なる属性を持っている場合は、複数のクラスを使用することが理にかなっている場合があります。