聚合的复杂性在哪里划清界限？澄清一下，如果我的聚合有一个 ObjectA 列表，其中有一个 ObjectB 列表，其中有一个 ObjectC 列表，我的聚合是否应该负责检索 ObjectC？或者我应该考虑创建另一个聚合以将这种复杂性降低到层次结构中的几个级别？
问问题
751 次
2 回答
7
在大多数情况下，聚合的边界应该是模型所需的一致性边界。这意味着如果对 ObjectA 或 B 或 C 的更改需要彼此保持一致，那么它们可能属于同一个聚合。
复杂性（业务逻辑复杂性）应该通过识别领域中的所有概念并在所涉及的实体/VO 之间拆分行为来处理。
对象检索复杂性（基础设施复杂性）应该由基础设施而不是聚合来处理。
总之，根据您的领域和一致性边界对您的 AR 建模，而不是为了解决基础设施问题。
于 2011-05-31T07:41:05.930 回答
1
就像 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 之外的其他实体有任何关联？
于 2011-06-01T13:02:43.620 回答