具有实体树的域聚合根

Question

我的聚合根 Node 的一个属性是树状的实体组Task。喜欢

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

Task 的树可能非常大，因此不会完全加载到内存中。我可以实现某种类型的对象延迟加载或动态查询。此外，我需要一种简单的方法来使用诸如 Task::addSubtask 之类的函数添加新任务...但我的直觉告诉我，这些解决方案在很多层面上都是错误的。

我试图从这个问题中吸取一些关于 DDD 的教训。所以我想找到对这些假设的确认。

1. 任何聚合根都应始终完全加载。任何部分加载都需要子组件能够执行查询（通过 repo、存储的查询...），这会破坏许多规则：单一职责、对持久性机制的无知...（注意：我没有 ORM默认提供延迟加载的层）

2. 内存中任务的“树形”实际上只有 GUI 中的大纲视图才需要。因此，我应该有一个虚拟组合，可以对我的领域模型的服务层执行查询。

3. 由于没有理由在 Node 的上下文之外有一个 Task，我的节点存储库应该处理任何需要树探索的操作，例如： p>

   (List*) findChildrenOfTask(Task* aTask)

   (List*) findChildrenOfTask(Task* aTask, String regexInText)

   (void) addChildToTask(Task* aTask)

这些是我的假设，但我想与具有更多 DDD 经验的人确认它们。 “仅在 GUI 中的树”似乎也激发了 CQRS 的一些想法。这个问题是对 DDD 采用 CQRS 的好处的一个例子吗？

Answer 1

这个确切的例子实际上在 Vaughn Vernon 的书实施领域驱动设计

中得到了解决

也就是说，我邀请您思考以下问题：

• 任务是否需要在事务上与 Node 保持一致？如果不是，它可以是它自己的 Aggregate，它极大地简化了事情。请记住，您是从ONLY命令的角度考虑这一点的。
• 如果树仅用于查询，为什么不让 DTO 担心这一点，而不是损害您的域模型？

我完全承认弗农在解释这一点方面做得比我好得多。