domain-driven-design - ドメインモデルの保存

Question

最近、Eric Evans の Domain Driven Design を読み終えました (非常に有益で、非常に楽しいものです) が、本を完成させてから最初の主要なプロジェクトに来て、ドメインモデルの保存方法を処理する方法を知りましたか?

サービス/リポジトリの使用と、それらがモデルをどのように支援できるかを評価しますが、モデルの保存をどのように処理しますか?

私の以前のドメインモデルの保存は、次のメソッド呼び出し構造に従います。

ParentClass.Save {

ParentClassDB.Save

ChildObject1.Save

       ChildObject1DB.Save

ChildObject2.Save

       ChildObject2DB.Save  
  etc etc

}

サービスは、子オブジェクトに対する適切な保存ルーチンの呼び出しを制御しますか?

score 6 · Accepted Answer

DDD では、ドメインエンティティはその永続性を考慮しません。Save()理想的には、メソッドを持たないでください。

リポジトリにはSave、パラメーターにエンティティインスタンスを受け取るメソッドがあります。

public class PersonRepository
{
   //...

   public void Save(Person person)
   {
      this.dataContext.Save(person);
   }

   //...
}

スタックに応じて、ORM がオブジェクトの保存を処理するか、ユーザーを保存するためのクエリを作成して終了するか、インスタンス値からストアドプロシージャのパラメーターを入力するかなどです。

あなたがしたことを正しく理解していれば、ドメインエンティティに配置した永続化ロジックを別の場所、おそらくリポジトリ、またはリポジトリで使用される DAL に移動する必要があるかもしれません。

score 1 · Accepted Answer

集約ルートを使用していますか? 彼らは、エンティティを保存する責任があります。

多数の変更が行われている場合、1 つの方法として、そのロジックをドメインサービスにカプセル化し、そのサービスに Aggregate ルートを介して保存を処理させることができます。

domain-driven-design - ドメイン モデルの保存