私は DDD とそれが MVC にどのように関係するかについて頭を悩ませようとしていますが、エンティティの識別に関しては問題があります。
特に、プレゼンテーション、ドメイン、およびデータ モデルを厳密に分離するようにしています。ここでの問題は、これらの境界を越えてエンティティの識別を保持する方法にあります。明確にするために、異なるコンテキストで同じエンティティを表すために別々のクラスを使用しています。 「shipment_request」データベース テーブル (私のデータ モデル)。
「ID」プロパティ (ShipmentRequestId など) を使用すると、達成しようとしている分離に違反するように感じます。この ID プロパティはデータベースの問題であり、ドメインの問題ではないためです。レイヤー間で同じオブジェクトを渡したくありません。これは、不要なデータをプレゼンテーションレイヤーに渡すことを意味するためです。
この分離を維持しながら、これらのレイヤー間のアイデンティティを追跡するにはどうすればよいでしょうか?
エンティティに Id フィールドがないと、それをデータベース行にマップできません。したがって、この id フィールドは、エンティティとは関係ありませんが、ドメイン モデルに漏れる必要があります。
特に達成しようとしているものがいくつかのプロパティを非表示にする場合は特に、プレゼンテーション モデルを使用するのはほとんどの場合やり過ぎだと思います。
関心の分離は、主に境界付けられたコンテキストによって推進されると思います。たとえば、Person、PersonView、および Person テーブルはすべて、トランザクション処理コンテキストに関連しているようです。そのようなコンテキストでは、PersonView さえ持たないようにし、person テーブルは抽象化されます。
一方、レポートのコンテキストにいる場合は、PersonView の方が便利です。
コンテキストは、レイヤリング スキームよりもはるかに重要だと思います。
person エンティティに自然キーがないということは、 Person が実際にはエンティティではないことを意味している可能性があります。たとえば、実際のアプリケーションでは、常に個人に関連付けられた番号があります。従業員には従業員番号、クライアントにはアカウント番号などがあります。このビジネス ID は間違いなくドメインの一部です。
Shipment Request は間違いなくより良い例です!
ユーザーはどのようにして出荷リクエストを見つけますか? 回答によっては、20091012-A など、ユーザーが覚えている ID が必要になる場合があります。
出荷リクエスト ID は変更できますか? そうでない場合は、ID に db キーを使用します。
あるシステムから別のシステムに出荷リクエストを転送する必要がありますか? はいの場合、ID に db キーを使用しないでください。
どのようなキーを使用する場合でも、特定の出荷リクエストに対するアクションへのリンクを作成できるように、プレゼンテーション モデルで使用できるようにする必要があります。
エンティティに「ID」フィールドを持つことは、多くの (ほとんどの?) 人々が譲歩することであり、そうすることに罪悪感を感じることはないと思います。
おっしゃる通り、データベースを扱っていない場合でも、アイデンティティの概念が必要です。エンティティごとにある種の「自然な」ID (名前のようなフィールド、または複数のフィールドの組み合わせ) を考え出すことはできますが、これが常に可能であるとは限りません。その場合でも、ID フィールドを持つことは、「名前が X、生年月日が Y、SSN が Z であるエンティティ」と言うための便利な短縮形として機能することがよくあります。
最終的には、間違いなく「純粋」ではありませんが、ID フィールドを使用すると、物事が大幅に簡素化される可能性があります。