domain-driven-design - DDD : How to handle large collections

Question

我目前正在为 REST 中的社交网络相关应用程序设计后端。我对 DDD 原则非常感兴趣。现在让我们假设我有一个拥有 friend 集合的用户对象。如果应用程序和用户变得非常成功，这些可能会达到数千。每个 friend 也会有一些属性，它基本上是一个用户。
看着DDD Cargo application example ，完全扩展的 Cargo-object 会不时地从 CargoRepository 存储和检索。哇，如果聚合根中有一个列表，随着时间的推移，这最终会触发 OOM。如果您从以数据为中心的角度处理问题，这就是为什么会有分页和延迟加载的原因。但是你如何在一个不知道持久性的 DDD 中处理这些大集合呢？

Answer 1

正如评论中提到的@JefClaes:您需要确定您的User AR 确实需要 Friends 的集合.

所有权并不一定意味着收集是必要的。

采取Order/OrderLine例子。一个 OrderLine没有成为 Order 的一部分就没有任何意义.但是，Customer那个Order属于没有 Orders 的集合.它可能有 ActiveOrders 的集合如果客户被限制为最大数量(或金额)iro 事件订单。保留历史订单的集合是不必要的。

我怀疑大型收集问题不仅限于 DDD。如果有人收到 Order有数千行可能会在设计上有所取舍，但订单可能更容易被简单地拆分为更小的订单。

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

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

所以也许是 Relationship AR 可以在这方面有所帮助。