2

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

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

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

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

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

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

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

    (List*) findChildrenOfTask(Task* aTask)

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

    (void) addChildToTask(Task* aTask)

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

4

1 回答 1

4

这个确切的例子实际上在 Vaughn Vernon 的《实现领域驱动设计》一书中得到了解决

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

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

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

于 2013-06-26T14:31:14.853 回答