对象的结构（图）是值得存储库的聚合根吗？

Question

哲学 DDD 问题在这里...

我在这里看到了很多 Entity 与 Value Object 的讨论，但我的情况略有不同。如果之前已经报道过，请见谅。

我目前在金融领域工作。我们有资金（对冲品种）。这些基金通常投资于其他基金。这导致了一种树状结构，顶部有一个基金将它们锚定在一起。

显然，基金是一个实体（Aggregate Root，甚至）。交易和头寸之类的东西很可能是价值对象。

我的问题是：树结构本身是否应该被视为聚合根？ 一些想法：

• 树结构通过存储组件和它们彼此的位置存储在数据库中。我们目前没有编码树的概念。域很弱。
• 树结构没有“唯一性”或标识符。
• 在许多地方都需要逻辑来“遍历”树以查找彼此之间的关系，要么自上而下，要么有时自下而上。这个逻辑需要封装在某个地方。
• 有很多逻辑可以计算杠杆率、曝光率等...并将其汇总到树上。

将 Fund 视为 Composite Fund 对象是否足够好，即内置 Invariants 的聚合根？或者在这种情况下更正式的树结构有用吗？

Answer 1

我通常采用更具功能性/领域性的方法来设计我的聚合和聚合根。

这会产生一种树状结构

也许您可以与您的领域专家交谈，看看该概念是否值得成为一等公民，并以无处不在的语言（FundTree、FundComposition...？）拥有自己的名字。

一旦完成，使其成为聚合根基本上取决于您是否认为实体是应用程序中的主要入口点之一，即您有时是否需要在引用 FundTree 之前甚至引用一个基金，或者如果你只能通过基金的遍历来获得它。

Answer 2

这更多的是决定您是否真的要始终加载完整的树。

如果您对定义为聚合根的内容不屑一顾，那么您会发现很多膨胀，因为您将在任何时候加载完整的对象树。

没有一种适合所有方法的方法，但我认为，您应该尽可能将您的关系全部映射到聚合根，但在某些情况下，该树的一部分可以被视为聚合根需要。

如果您在网络环境中，这与桌面应用程序不同。

在网络中，每次页面加载都会重新开始，所以我倾向于有一个很好的模型来映射关系和几乎每个实体的存储库（因为我总是需要从一些弹出窗口中保存一小部分内容某处）并将其与每个聚合根完成的服务拉在一起。它使代码可预测并阻止那些......“嗯......这是一个根”时刻或变得无法管理的存储库。

然后我会有映射器，可以在需要时为我提供大树的摘要和/或列表项视图。

在桌面应用程序中，您将更多的东西保存在内存中，因此您只需计算出聚合根是什么并在需要时加载它们，就可以减少编写代码。

这没有对错。我怀疑您是否可以构建任何类型的大型应用程序而不会对被视为聚合根的内容做出妥协，并且您最终总是会遇到两个根最终在某个地方相互连接的情况。