web-dev-qa-db-ja.com

ドメインモデルにIDがないのは正常ですか？

本を読んだ後;私は次のことを理解しました：

1）エンティティは平等を実装し、IDごとに比較する必要があります。 2）値オブジェクトは同等性を実装し、クラスのすべてのプロパティで比較する必要があります。

私は、ポイント2の私の理解が正しいとまだ信じています。ただし、次の理由により、ポイント1について混乱しています。

1）このブロガーは、すべてのエンティティが継承するエンティティ基本クラスの作成について話します： http://enterprisecraftsmanship.com/2014/11/08/domain-object-base-class/ 。したがって、等価比較は基本クラスで定義されているため、すべてのエンティティはIDによる等価を実装します。

2）ここにあるほとんどのエンティティークラスにはIDがあります： https://github.com/nhibernate/nhibernate-core/tree/master/src/NHibernate.DomainModel/Northwind/Entities

3）この質問は、ID属性があることを示唆しているようです： DDDのドメインオブジェクトのIDプロパティ

4）この質問は、エンティティにIDがあってはいけないと主張されているYouTubeビデオ（ポイント1）を指しています。

上記のポイント1〜4は、次のいずれかを示唆しているようです。1）データベースIDを使用します。 2）データベースIDではない別のIDを使用します。 3）IDを使用しません。

私は以下のことを決定しようとしています：

1）エンティティーのスーパークラスを用意します。

または2）すべてのエンティティに（データベースの）IDがある。

または3）ドメインオブジェクトを識別する識別子（データベースIDではない）を導入します。

ドメインモデルを完全に分離しようとしています（データモデルもあります）。

c#domain-driven-designentity
3
w0051977

定義により、entitiesはアイデンティティを持っています。

このこと自体は、エンティティオブジェクトにIdプロパティが必要であることを意味するものではありません。エンティティを集計の外で参照または比較する必要がない場合は、実際には必要ありません。

ただし、通常、すべてのエンティティがIDを持つことは理にかなっています。 Idはどこから来たのですか？特別な理由がない限り、アプリケーションではデータベースではなくIDを作成することをお勧めします。 UUID（C＃ではGuid）またはいくつかのカスタムIdGeneratorを使用できます。データベースがId値をキーとして使用する可能性があるという事実は、ドメインモデルに関する限り、まったくの偶然です。

これは、Entity基本クラスの問題を残します。作成したくない理由はいくつかあります。

  • Entityはドメインの概念ではないため、ドメインオブジェクトをそれに依存させることは理想的ではありません。

    Idもドメインの概念ではないと主張するかもしれません。それを脇に導入する実用的な理由は、アイデンティティisが暗黙のドメインの懸念であると主張します-それ以外の場合は、単に値オブジェクトを使用できます。

  • Entityの機能はほとんどありません。 Idプロパティと、おそらく非常に安定した1行（this.Id == other.Id）等価チェックはやり過ぎのようです。

そうは言っても、Entity基本クラスが原因で問題が発生する可能性は非常に低いと思います。したがって、ドメインロジックに集中するのに役立つ場合（たとえば、これがEqualsをオーバーライドすることを忘れないようにすることで、これが等価性チェックの実装方法である場合）、必ずそれを実行してください。

8
doubleYou