【发布时间】：2011-05-31 05:08:02
【问题描述】：
在聚合的复杂性中如何划分界限？澄清一下，如果我的聚合有一个 ObjectA 的列表，其中有一个 ObjectB 的列表，其中有一个 ObjectC 的列表，我的聚合是否应该负责检索 ObjectC？或者我应该考虑创建另一个聚合以将这种复杂性降低到层次结构中的几个级别？
【问题讨论】：
标签： domain-driven-design aggregateroot
【发布时间】：2011-05-31 05:08:02
【问题描述】：
在大多数情况下，聚合的边界应该是模型所需的一致性边界。这意味着如果对 ObjectA 或 B 或 C 的更改需要彼此保持一致，那么它们可能属于同一个聚合。
复杂性（业务逻辑复杂性）应通过识别领域中的所有概念并在所涉及的实体/VO 之间拆分行为来处理。
对象检索复杂性（基础设施复杂性）应该由基础设施而不是聚合来处理。
总之，根据您的领域和一致性边界为您的 AR 建模，而不是为了解决基础架构问题。
【讨论】：
-
感谢您的回答！所以，我认为检索对象的方式是一个基础设施问题。但这在确定哪些实体应该是 AR 时不是必需的吗？在某些情况下，从 ObjectA 聚合根访问 ObjectB 是合乎逻辑的，但在另一个上下文/用例中，ObjectB 很可能是它自己的聚合根。那么，基础设施问题毕竟不是决定性因素吗？
-
基础设施问题不应决定您的 AR 界限。你的一致性要求应该。这个想法是，您域中的概念可以是一个边界上下文中的 AR 和另一个边界上下文中的实体。直接访问实体违背了拥有聚合的目的——即强制不变量和一致性。我建议您观看Eric Evans video，然后重新阅读 DDD 书中有关边界上下文的章节。您的用例是确定 BC 的良好开端
就像 lulian 说的，我猜没有规则可以说明您的 AR 应该是什么样子。如果您的带有 ObjectA、B 和 C 的 AR 属于相同的业务上下文，那很好。但我认为您还应该反思您的客户/用例如何使用您的模型。如果您总是希望 ObjectC 和从 ObjectA 和 B 到 C 的对象图遍历感觉像是不必要的遍历，那么您的模型可能不正确。
如果您的根对象是 ObjectA 并且您有一个 ObjectARepository，您可以随时添加存储库方法，例如 GetObjectCsByObjectA(ObjectA objectA)，它将列出 A 的所有 C。 如果一个 ObjectC 可以是多个 ObjectB 的子对象，那么上述解决方案可能不是最好的解决方案，因为您为一个 A 获得了所有 C。
最重要的是您的 GUI/客户端将如何使用此 AR（重复我自己...） 您可以添加扩展方法来添加 Linq 过滤器或搜索，以简化从 A 到 C 的遍历。不是我最喜欢的，但它有效。更好的办法是尝试使用值对象或只是一个简单的 listwrapper 类将 ObjectB 的集合包装在 ObjectA 中，该类不持久，只是在访问此集合时创建。此包装器可以提供适合您的 GUI 的必要访问方法以及添加、替换和删除列表项时的验证。包装器将成为您的客户的快捷方式，因此他们无需担心 AR 是如何在 AR 中构建的。
ObjectB 和 ObjectC 是否与此 AR 之外的其他实体有任何关联？
【讨论】：
-
你是对的，在阅读回复后，规则是它完全是上下文相关的。我必须同意你的观点，确定 AR 是一个不仅与域边界耦合的过程，而且还与用例耦合。如果不查看用例，我不知道我怎么知道我的聚合中的任何对象本身是否可以是一个聚合。要回答您的最后一个问题，是的，ObjectC 确实在 AR 之外还有其他关联。
-
一个共同的准则是 AR 中的所有子对象都不应在 AR 边界之外有关联。为什么？好吧，如果你想删除/删除根实例，它的所有 AR 子对象也应该被删除。如果 child 像具有外部关联的 ObjectC 一样，这可能是一个棘手的操作。也许您需要将 ObjectC 升级为具有自己存储库的 AR？子实体可以是其他 AR 中的 AR。
-
“父/子”可能不明确。按照 Evans 模型，AR不能既是 AR 又是另一个 AR 的成员。两个 AR 可以有关系。外部对象只能引用 AR，但 AR 中的实体可以保存外部引用。 ObjectA 中的 ObjectC 列表不授予聚合成员资格。如果 ObjectC 真的是 AR，那么它就是 AR-AR 关系。如果 ObjectC 确实是 ObjectA AR 的一部分，那么 ObjectC 也不能是 AR。仅存在从 ObjectA 到 ObjectC 的引用不足以区分这两种可能性。 AR 是概念性的，不能仅通过代码来表达。