哲学DDD问题在这里......
我在这里看到了很多Entity与Value Object的讨论，但我的情况略有不同。请原谅我，如果之前已经讨论过这个问题。
我目前正在金融领域工作。我们有资金（对冲品种）。这些资金通常投资于其他基金。这导致了一种树形结构，顶部有一个基金将它们固定在一起。
显然，基金是一个实体（Aggregate Root，甚至）。交易和头寸之类的东西很可能是价值对象。
我的问题是：树结构本身应该被视为聚合根吗？ 一些想法：
将基金视为Composite基金对象并且内置Invariants的聚合根是否足够？或者在这种情况下是一个更正式的树结构？
答案 0 :(得分：2)
我通常采用更多功能/域方法来设计我的聚合和聚合根。
这导致了各种树的结构
也许您可以与您的域名专家交谈，看看这个概念是否值得成为一流的公民，在无处不在的语言中拥有自己的名字（FundTree，FundComposition ......？）
一旦完成，将其作为聚合根将基本上取决于您是否认为该实体是应用程序中的主要入口点之一，即您有时甚至在引用之前需要引用FundTree基金，或者只有通过遍历基金才能获得基金。
答案 1 :(得分：1)
这更像是一个决定你是否真的想要加载完整的树。
如果你是关于你定义为聚合根的肛门，那么你会发现很多臃肿，因为你在加载它们时会加载完整的对象树。
没有一种适合所有方法的方法，但在我看来，您应该尽可能将您的关系映射到您的聚合根，但在某些情况下，可以将该树的一部分视为聚合根。需要的。
如果您在网络环境中，这是对桌面应用程序的不同决定。
在网络中，你再次开始每个页面加载，所以我倾向于有一个很好的模型来映射关系和几乎每个实体的存储库（因为我总是需要从一些弹出窗口中保存一小部分内容）在某处）并将其与每个聚合根完成的服务一起拉出来。它使代码可以预测并停止那些......“嗯......这是一个根本”的时刻或存储库变得无法控制。
然后我会有mappers，可以根据需要和需要时为我提供大树的摘要和/或listitem视图。
在桌面应用程序上，您可以将内容保存在内存中，因此只需计算出您的聚合根源并在需要时加载它们就可以编写更少的代码。
这没有对错。我怀疑你可以构建一个任何类型的大型应用程序，而不会在被认为是聚合根的情况下做出妥协，并且你总是会在一个两个根最终在某个地方相互连接的引用中结束。