在聚合的复杂性中，哪一条划线？为了澄清，如果我的聚合有一个ObjectA列表，它有一个ObjectB列表，它有一个ObjectC列表，我的聚合应该负责检索ObjectC吗？或者我应该考虑创建另一个聚合来将这种复杂性降低到层次结构中的几个级别？
答案 0 :(得分：7)
在大多数情况下，Aggregate的边界应该是模型所需的一致性边界。这意味着如果对ObjectA或B或C的更改需要彼此一致，那么它们可能属于同一个Aggregate。
复杂性（业务逻辑复杂性）应该通过识别域中的所有概念并在涉及的实体/ VO之间拆分行为来处理。
检索复杂性（基础架构复杂性）的对象应由基础架构处理，而不是由聚合处理。
在结论模型中，您根据您的域和您的一致性边界进行AR，而不是为了促进基础设施问题。
答案 1 :(得分：1)
像lulian所说，我猜没有规则说明你的AR应该是什么样的。如果你的AR与ObjectA，B和C属于同一个业务环境，那就好了。但我认为您还应该反思您的客户/用例如何使用您的模型。如果你总是想要ObjectC和从ObjectA和B到C的对象图遍历感觉就像一次不必要的遍历，那么你的模型可能不正确。
如果你的根对象是ObjectA并且你有一个ObjectARepository，你总是可以添加一些存储库方法，比如GetObjectCsByObjectA（ObjectA objectA），它将列出A的所有C。 如果一个ObjectC可以是几个ObjectB的子代，那么上面的解决方案可能不是最好的，因为你获得了一个A的所有C。
最重要的是您的GUI /客户端将如何使用此AR（重复自己...） 您可以添加扩展方法来添加Linq过滤器或搜索以简化从A到C的遍历。不是我最喜欢的但它可以工作。更好的方法是尝试使用Value Object或只是一个简单的listwrapper类在ObjectA中包装ObjectB的集合，该类不是持久化的，只是在访问此集合时创建的。在添加，替换和删除列表项时，此包装器可以提供适合您的GUI的必要访问方法以及验证。包装器将是您的客户端的快捷方式，因此他们不需要打扰如何在AR内部构建AR。
ObjectB和ObjectC与此AR之外的其他实体有任何关联吗？