**Update 2**
典型的な 3 層構造 (UI/ドメイン/データ層) のプロジェクトがあります。ドメイン レイヤーとデータ エンティティ レイヤーの両方のドメイン モデル エンティティを持つことの長所と短所は何ですか。
別のデータベースに変更する可能性はわずかです。データ層にデータ エンティティのみをドメイン モデル エンティティとして持つことの長所と短所は何ですか? ORM が使用されている場合の違いは何ですか (ORM (NHibernate) が使用されている場合、両方のエンティティを使用することをお勧めします)?
あなたのアイデア、またはリンク、記事、本を発射してください。
アップデート 3
どのような状況で、ドメイン エンティティとデータ エンティティの両方を使用する必要がありますか?
データスキーマがドメインエンティティに正確にマッピングされていない場合は、データエンティティを使用します。たとえば、電話番号について考えてみます。ドメインエンティティでは、単一のプロパティである場合がありますが、データベースでは、市外局番フィールドと電話番号フィールドで構成されている場合があります。
いくつかの回答が示唆していることに反して、データアクセス層はドメインエンティティを水和せず、それらについての深い知識を持っていません。代わりに、ドメインレイヤーは、インスタンスの再構築に必要なデータをデータアクセスレイヤーに要求します。
あなたの質問がDDDについてであると仮定します。典型的なDDDシナリオでは、ドメインエンティティはデータレイヤー（ORMを使用するため薄いことが多い）によって「ハイドレイト」されます。ドメインエンティティをハイドレイトするために、データレイヤーはドメインに関する深い知識を持っている必要があります。個別の「データエンティティ」を必要としない可能性が高いよりもORMを使用する場合、ORMはドメインオブジェクトを再構成する方法を知っています。お役に立てれば。
データ エンティティをドメイン エンティティと共に使用するのは難しい作業であり、価値を追加することなく、不要な別の抽象化レイヤーを追加します。
ORM を介してマッピングされたフル機能のドメイン モデルまたは「anaemic」データ モデル (ORM を介してマッピングされた) のいずれかを使用する必要があります。どちらがあなたの背景、要件、個人的な好みによって異なります。
データ モデルの場合、継承階層マッピングのような複雑なことをせずに、おそらくテーブルをエンティティに (1 対 1 で) 直接マッピングします。それはいいです。注意が必要なのは、1:n の関係をマッピングすることです。オブジェクトモデルで「多」側を表現しない場合、データモデルではうまく機能する傾向があります。なんで？これらのケースを処理するカスタム コードを追加しないと、両方のリレーション エンドが簡単に同期しなくなるためです。
ドメイン モデルの場合、おそらくリポジトリを使用して集約ルートを取得します。
私が書いたことには例外があります。CQRS アーキテクチャでデータ エンティティとドメイン エンティティの両方を使用することは正当です。
ドメイン モデルは、コードの再利用と理解を最大化するために、できるだけ多くの場所に存在する必要があります。これに対する例外は、ドメイン モデルを使用すると、時間、メモリ、または輸送コストのいずれかが法外に高くつく場合です。
部品のサプライヤーがいるとしましょう。このサプライヤは何千ものパーツを提供しているため、この場合の 1 対多は巨大になる可能性があり、特に各パーツがもたらす可能性のあるクラスの網を考えるとそうです。ただし、特定のウィジェットの特定のサプライヤーからの部品のリストが必要です。この場合、必要なデータだけを含む値オブジェクトを作成します。
この値オブジェクトは、必要な部分のみを含むサプライヤ オブジェクトのコピーにすることも、必要なデータのみを表す完全に新しいクラスにすることもできます。
これの典型的な使用例は、Web ページにデータを表示し、json を介してデータを転送することです。