2

私の集約ルートNodeの 1 つのプロパティは、エンティティTaskのグループのようなツリーです。お気に入り

- Node
    - Name
    - Release
    - User
    - task
       - task
       - task
            - task
       - task

Taskのツリーは非常に大きくなる可能性があるため、完全にはメモリにロードされません。ある種のオブジェクトの遅延読み込みまたは動的クエリを実装できます。さらに、Task::addSubtask... のような関数を使用して新しいタスクを簡単に追加する方法が必要になりますが、私の直感では、これらのソリューションは非常に多くのレベルで間違っていることがわかります。

この問題から DDD についていくつかの教訓を得ようとしています。したがって、これらの仮定の確認を見つけたいと思います。

  1. 集約ルートは常に完全にロードする必要があります。部分的なロードでは、サブコンポーネントがクエリを実行できるようにする必要があります (レポ、保存されたクエリを介して...)。これにより、多くのルールが妨げられます: 単一の責任、永続化メカニズムの無視... (注: ORM はありませんデフォルトで遅延読み込みを提供するレイヤー)

  2. メモリ内のタスクの「ツリー形状」は、実際には GUI のアウトライン ビューでのみ必要です。したがって、ドメイン モデルのサービス層に対してクエリを実行できるダミーのコンポジットが必要です。

  3. Nodeのコンテキスト外にTaskを持つ理由はないので、私のノード リポジトリは、次のようなツリーの探索を必要とするすべての操作を処理する必要があります。

    (リスト*) findChildrenOfTask(タスク* aTask)

    (リスト*) findChildrenOfTask(タスク* aTask, 文字列 regexInText)

    (void) addChildToTask(Task* aTask)

これらは私の推測ですが、DDD の経験が豊富な人に確認したいと思います。「GUI のみのツリー」も、CQRS のアイデアのいくつかのアイデアに拍車をかけているようです。この問題は、DDD に CQRS を採用する利点の 1 つの例ですか?

4

1 に答える 1

4

この正確な例は、実際には Vaughn Vernon の著書Implementing Domain Driven Designで取り上げられています。

そうは言っても、次のことを熟考してください。

  • タスクはノードとトランザクション的に一貫している必要がありますか? そうでない場合は、物事を劇的に簡素化する独自の Aggregate にすることができます。コマンドONLYの観点からこれについて考えていることに注意してください。
  • ツリーがクエリ専用である場合、ドメイン モデルを危険にさらす代わりに、DTO にそのことを心配させませんか?

Vernon は、私よりもはるかに優れた説明を行っていることを十分に認めます。

于 2013-06-26T14:31:14.853 に答える