4

図に示すように、比較的単純なドメイン モデルがあります。DDD で定義されているように、ドメイン オブジェクト内でこのロジックを維持したいと考えています。

各ドメイン オブジェクトは、それぞれのメンバーとドメイン ロジックのみを含む抽象クラスです。これらのクラスの具体的な実装は、(DI を使用して) サービスに提供されるリポジトリによって返されます。

私が問題を抱えているのは、新しいエンティティを作成する必要がある状況に対処する方法を理解することです. たとえば、ドメイン ロジックは次のように指示します。

アカウントを に追加できます(エンティティのGroup作成)。Member

  • アカウントがグループに追加されるとき、新しいMemberエンティティのValueプロパティは、 に既に存在するメンバーの総数に設定する必要がありますGroup。

  • グループの他のすべてのメンバーは、値を 1 ずつ増やす必要があります。

Member AddMember(Account account)これを のメソッドとして実装できますGroup。ただし、このメソッドは何らかの方法で新しいインスタンスMemberを作成して、グループのメンバー コレクションに追加する必要があります。

ドメイン オブジェクトにはアプリケーション内のさらに上位のレイヤーへの参照がなく、ドメイン オブジェクト自体が抽象的であるため、Member の新しいインスタンスを構築する方法がわかりません。

具体的な実装で実装できるオブジェクトのabstract protected Member CreateMember()メソッドを定義する可能性を検討しましたが、これは面倒に思えて、もっと基本的なことを誤解している可能性があるのではないかと懸念しています。Group

DDD の原則に忠実であり続けるために、このモデルをどのように実装すればよいでしょうか?

ドメイン エンティティ図

4

2 に答える 2

2

おそらく、新しいメンバー オブジェクトを作成する役割を持つ MemberFactory を (ドメイン サービスとして) 作成する必要があります。良い例については、この回答を参照してください。

于 2012-07-16T13:16:12.637 に答える
1

ここでの根本的な問題は、ドメインオブジェクトが抽象的であるという事実だと思います。ドメインオブジェクトは、ほとんどの場合、必要なすべてのドメインロジックを実装する具象クラス（いくつかの例外はありますが）である必要があります。

リポジトリは、外部データソース（データベースなど）への単なるインターフェイスであり、ドメインの動作に影響を与えることはありません。リポジトリにオブジェクトの実際の実装を返すようにすることで、ドメインロジックをリポジトリと結合します。

エンティティが具体的なクラスになるように、設計を再考する必要があります。一緒に、ドメインオブジェクトは、外部サービス/リポジトリに関係なく、すべてのドメインロジックを実装する必要があります。

于 2012-07-16T16:12:32.887 に答える