加载所有实体作为聚合根的一部分

Question

从我在线阅读的内容来看，从数​​据库加载时的聚合必须处于完整状态。这意味着它必须有权访问其中也从数据库加载的所有实体，以便聚合永远不会处于无效/不完整状态。

如果聚合包含一个可能有数百万个实体的实体，例如。 Aggregate A 包含 Entity B 和 Entity C。现在最坏的情况是，Aggregate A 下最多可以有 100 个Entity B 实例，但Aggregate A 下可能有数百万（如果不是数十亿）Entity C。

---

用例：

用例是我想使用 Id 从Aggregate A 中删除Entity C 的一个特定实例。要以DDD 方式执行此操作，我必须首先从数据库中加载Aggregate A 并将其所有实体加载到内存中。然后可以使用以下方法删除该项目：

public class AggregateA extends AbstractAggregateRoot<AggregateA>{

     private String aggregateId;

     private Map<String, EntityC> entityC;

     public void removeEntityC(String idToRemove) {
           this.entityC.remove(idToRemove);
           registerEvent(new EntityCRemoved(aggregateId, idToRemove));
     }
}

---

问题：

将数百万个实体加载到内存中以针对单个请求执行任何Write Operation (Command in CQRS) 似乎不是正确的方法。

我错过了什么吗？

Answer 1

您误解了 DDD 的“加载完整聚合”任务。就像你说的那样，这样做是完全不切实际的。我的建议是加载所需的聚合的完整部分。

例如：我的操作（尽管是人为的）是编辑具有数百万 cmets 的博客条目中的特定博客评论。我要做的是加载博客聚合和我试图从存储库更新的单个评论。然后我会继续让博客聚合更新评论。当然，另一种设计选择是仅加载注释（因为您可以使用它的 id 来识别它），但这将加载一个不完整的实体，因为它会丢失聚合根（这是任务要求不要做的） )。

这里的一个问题当然是在 DDD 中进行批量更新效率低下。这是设计上的弱点，也是在 DDD 之外解决的问题。

Answer 2

我认为这将是重新考虑您的总体界限的第一个迹象。一种可能的解决方案是将实体 C 视为聚合，并通过 id 引用聚合 A。这取决于您的业务领域，因此这只是一个模糊的建议。您可以在聚合 A 中或在生成聚合 C 实例的单独域服务中使用工厂方法。一般而言，您应该避免在聚合中加载数百个实体，因为它将跨越该聚合周围的巨大事务边界。

public class AggregateA {
    public AggregateC createAggregateC(...){
        //create AggregateC and return it with reference set to AggregateA
        return new AggregateC(this.id, ...)
    }
}