DDD - 聚合根负载/查询性能答案

【问题标题】：DDD - Aggregate Root load/query performanceDDD - 聚合根负载/查询性能
【发布时间】：2013-03-13 12:58:41
【问题描述】：

我正在玩 DDD，然后弹出这个问题。我如何加载子聚合根？会出现几个性能问题。想象一下下面的例子：

public AggregateRoot1
{
     #region
        properties
     #endregion

     public AggregateRoot2 AR2{get;set;}

     public IEnumerable<AggregateRoot3> AR3List{get;set;}

     (...)
}

如果我在获取 AggregateRoot1 时加载 AggregateRoot2 和 AggregateRoot3 列表，则该图会很大。这似乎不是一个好方法。

我有两个选择：

将 AggregateRoot2 AR2 替换为 Guid AR2Id 和 IEnumerable AggregateRoot3> AR3List 替换为 IEnumerable Guid> AR3ListIds。所有 AR 引用都应替换为 ID。
因为我不喜欢 IEnumerable ARListIds 方法，所以我正在考虑删除 0...* 对 AR 的引用。所有需要 AR 的列表数据的操作都应该通过像 David Masters 这样的域服务进行 sugest here

顺便说一句，我不考虑使用延迟加载。

我期待听到您对儿童 AR 加载的意见。谢谢

【问题讨论】：

标签： domain-driven-design cqrs ddd-repositories aggregateroot

【解决方案1】：

理想情况下，聚合之间的引用应该仅通过身份进行。这是选项 1。但是，您应该评估每个参考，以查看是否需要参考持有聚合的一致性。有时，两个聚合之间的关系本身可以成为单独加载的聚合。总体而言，请查看Effective Aggregate Design by Vaughn Vernon，以深入分析设计聚合时的各种权衡。这也是 David Masters 在链接问题中所指出的。

【讨论】：

@eulerfx-感谢您的回复。我同意引用另一个具有 ID 的聚合根，但是 AR 的集合怎么样。应该在 AR 的 ID 数组中转换吗？我从来没有见过类似的实现，我看到的例子只是1-1的关系。
此外，由于Guids不是通用语言的一部分，如果您确实需要它们来确保业务不变量，您应该使用shared identifiers。
AR id 的集合可以使用，请看这里：github.com/MarkNijhof/Fohjin
我同意 eulerfx 并想补充一点，我不认为加载整个对象图通常是一个大问题，因为这是大多数 DI 容器所做的，除非这些对象从网络或硬盘。

【解决方案2】：

如果图表变得太大并且您不能使用延迟加载，这可能表明您的模型可以使用一些工作 - 您可能拥有应该作为它们自己的聚合根的实体。

通过使用工厂和存储库，可以更好地管理大型对象。您可以缓存大型对象，或在 AggregateRoot1 的工厂中实现单例模式。

遵循 DDD 的一个原因是对复杂性的封装。但是拥有非根对象的 ID 会破坏这种封装。虽然可能会考虑性能，但过早地优化代码以提高性能通常不会创造出好的软件。

【讨论】：

我同意你的观点，但问题的重点是引用子聚合根，或者你的聚合根永远不会引用另一个聚合根？重点在于子聚合根的负载。