Domain driven design DDD：用于引用非聚合根的解决方案

我有两个聚合根和两个非聚合根实体：

我知道，关系

D->B

违反了DDD原则

我听说，在大多数情况下，解决方案是使被引用的实体成为新的聚合根

---

但是如果B是a的真正孩子（B不能没有a而生存），那么将B变成一个新的聚合根真的是一种选择吗？

我同意你的观点，有时候将一个实体从它的聚合中分离出来是没有意义的，因为它非常自然地适合它。这就是为什么我没有完全接受一些人所说的“小总量”方法的原因之一

---

在这种情况下，您可以通过遍历a的实例而不是直接获取对B的引用。毕竟，如果B没有A就不能存在，那么聚合之外的对象就没有理由知道某个B而不知道它的A。

首先，这不是DDD思维，这是RDBMS思维。在DDD中，您可以像在真实世界中一样对业务流程进行建模，您没有一对多的etc概念。所以，忘掉数据库、外键等等吧

你的有界上下文（BC）是什么？每个聚合本身就是一个BC，因此它们可以有不同的概念表示，即使它们的名称相同

如果我理解正确的话，那么B C D似乎是单个聚合的一部分。这并不意味着它们仅以该聚合和该形式定义。然而，如果C在其他一些BC中是一个完全成熟的AR，那么在这个上下文中很可能只表示为一个id或几个属性（接口对于这种东西非常方便）。因此，即使它们都被命名为C，它们也是不同的，只有特定上下文所需的行为

DDD适用于许多BC，模型仅适用于一个BC。这意味着在你的应用程序中，根据每个BC，你将有多个A、B、C定义，每个定义可能略有不同。这意味着并非只有一种模型适用于所有情况（这里我不是说CQR，只是DDD）

---

我对这个领域了解不多，因此无法提出更具体的东西。但简单地说，试着按事物的本来面目和实际情况来表示事物。

我无法得到B的引用，因为我不知道具体的B。这个引用D->B至少需要持久化。你可以通过A在D中持久化检索B所需的信息。这样，您可以从C引用A，并让特定D实例通过A检索它们所需的特定B实例。这意味着，如果我使用O/R映射器，我无法对引用D->B强制执行完整性约束。我必须存储一些其他键（可能是D的主键），而不是在D中使用B的外键。性能问题可以通过将您的模型与域模型分离来解决。此外，我认为您不必完全放弃外键约束。关于您的用例的更多细节可能会对这个问题有所帮助。那么D呢，它是C的“真正的孩子”吗？是否有可能使D单独成为聚合根并反转引用？虽然很难说，如果没有领域知识，…+1设计聚合实际上是情境性的，一点上下文会有所帮助。在现实生活中，D被建模为一个关系实体，存储从C到B的定时一对多关系。定时意味着：B被分配给C，并且此分配在某个时间间隔内有效。这一次，C和B之间的关系属于C，因为这离不开C。该领域是能源物流市场。实体A是计量点操作员（德语：Messtellenbertreiber）。实体B是计量点的计量费（德语：Messentgelte）。实体C是计量点（德语：Messtelle）。实体D是计量点和计量费用之间的定时关系。Eric Evans在建模域时谈到了很多关于一个、一个多个等关系。此外，每个聚合也不是它自己的BC。