DDD：如何处理大型馆藏

Question

我目前正在为REST中与社交网络相关的应用程序设计后端。我对DDD原理很感兴趣。现在，假设我有一个拥有好友集合的User对象。如果应用程序和用户将变得非常成功，则这些数字可能为数千。每个朋友也将具有一些属性，它基本上是一个用户。查看DDD Cargo应用程序示例，有时会从CargoRepository中存储和检索完全展开的Cargo对象。哇，如果在聚合根目录中有一个列表，随着时间的推移，这最终会触发OOM。这就是为什么如果您从以数据为中心的角度来解决问题，则会出现分页和延迟加载的原因。但是，您如何在不具有持久性的DDD中处理这些大型集合？

Answer 1

正如@JefClaes 在评论中提到的：您需要确定您的UserAR是否确实需要Friends.

所有权并不一定意味着需要收集。

举个Order/OrderLine例子。AnOrderLine不属于an 的一部分就没有任何意义Order。但是，Customer一个Order所属的 没有 的集合Orders。ActiveOrders如果客户被限制为最大数量（或数量）iro 活动订单，它可能有一个集合。保留历史订单的集合将是不必要的。

我怀疑大集合问题不仅限于 DDD。如果收到一个Order包含数千条线的订单，则可能需要进行设计权衡，但订单更有可能被简单地拆分为更小的订单。

在您的情况下，我会断言 a 的包含/排除Friend与UserAR的一致性几乎没有关系。

需要记住的是，一旦您开始使用域模型进行查询，就会遇到各种奇怪的问题。因此，请始终尝试考虑一些具有简单查询接口的读取/查询模型，该接口可以直接访问您的数据，而无需使用您的域模型。这可能会简化事情。

因此，Relationship在这方面，AR 可能会有所帮助。