关于AggregateRoot边界的建议

Question

对于如何将DDD原则应用于具有聚合根的领域实体集群的设计，我感到困惑。根据我的理解，聚合根强制执行业务验证，聚合中的所有实体都应该从它的根访问。但这导致了大量的链接对象。

举个例子，我有一个包含3个实体的域：Contract、PurchaseOrder(PO)和Initative：

我认为Contract是集群的聚合根。用户可以添加Contract，然后为PO添加PO和Iniatives。但他(她)可以按PO号查找PO，并在其中添加Iniatiative。因此，每当我们添加一个计划时，我们都必须将整个Contract (与所有依赖项一起)加载到内存中，然后添加Initiative，这让人感到奇怪。

我可以从数据库中水合物化PO域实体，然后向它添加Initiative (根据所有的业务逻辑都在PO域实体中)，但这不违背不直接访问聚合集群的非根实体的DDD原则吗？

Answer 1

在您的问题中有两个不同的方面:域模型中的边界应该在哪里？以及如何实现您的模型？

模型

中的边界

集合的定义是：

一组关联对象，它们作为一个单元来处理数据更改。外部引用仅限于聚合的一个成员，指定为根。一组一致性规则适用于聚合的边界内。

读到你的问题，似乎：

• Purchase Order有一个唯一的ID，它完全独立于契约来标识对象。顺便说一句，这是正常的商业惯例:在任何情况下，即使不知道合同，也必须很容易地检索到任何PO (例如，收到订单的仓库工人不关心合同上下文)。
• 此外，您还说您很可能直接向PO添加一个计划。这表明您的模型的一致性不需要合同检查一致性。

这些事实强烈地表明，PO和Initiative可能在一个不包括Contract的集合中。您需要确认此扣减，通过反复检查，当您更改PO，添加一个主动性或更改一个计划时，合同不需要。另一个有用的问题是，当相关合同被“取消”或被删除时，POs会发生什么情况。

实现

当你谈到补水的时候.你在抱怨实现的事。在设计您的域模型时，不需要考虑这一点。实现面向对象数据库应用的模式有很多(例如身份映射、延迟加载等)。但是首先，你需要思考这个领域，并且很好地理解它。

例如，如果订单上的每一项更改似乎都需要交叉检查合同中的某些上限没有超出，反之亦然，合同中某些限制的更改需要实时检查新的价值仍然高于所有相关订单的总价值，那么直接更改PO似乎有点风险。那么，考虑集合根与契约毕竟是一个好主意。您将始终找到域和业务挑战的技术解决方案。例如，在超级聚合假设下，对PO数的查询很可能很好地返回相应的聚合。由您通过合同将变更传递给PO，以执行一致性。您还可以使用延迟加载原理加载聚合，但只加载严格需要的对象。