domain-driven-design - 从 DDD 的角度来看，我可以拥有非聚合根的存储库吗

Question

在我目前的（JPA）项目中，我基本上有 2 个实体。ChainOfClassesA 和 ClassA。现在 ChainOfClassesA 基本上是 ClassA (@OneToMany) 和其他几个属性的双向列表。对我来说，ChainOfClassesA 似乎是一个聚合根，因此有专门的存储库。现在，一个用例是更新 ClassA。我知道我可以为 ClassA 创建存储库，但这会违反规则“每个根聚合实体一个存储库”，因为 ClassA 并不是真正的聚合根，尽管这暗示我它可能是，或者我应该“扁平化 ChainOfClassesA ”。

现在我的问题是我应该务实并“打破规则”并为 ClassA 创建专用存储库还是遵循规则并将 ChainOfClassesA 中的双向列表 @OneToMany 替换为 ClassA 中对 ChainOfClassesA 的 ID 引用。第一种方法是实用的，只需要一点工作，而后一种方法还需要对代码库进行一些其他更改。你怎么认为？特别是为什么我不应该为非聚合根创建存储库（除非那个人可能会使用该存储库以便不再满足事务边界）

标签： domain-driven-designddd-repositories

Answer 1

如果 ChainOfClassesA 是一个聚合 Root 并且它有一个 ClassA 的集合。如果您需要一个用例来更新 ClassA，您可以在 ChainOfClassesA 对象上定义一个方法。我看不出 ClassA 有任何理由引用 ChainOfClassesA，因为它只能在 ChainOfClassesA 的范围内使用。如果 EF 允许您这样做，则不一定意味着您应该这样做。如果您为每个 ClassA 定义一个 repo，则意味着它可以完全独立于自己的生命周期。并且所有其他聚合最终都与它一致。如果删除 ChainOfClassesA，ClassA 是否应该继续存在？如果是，那么 ClassA 可能应该是一个单独的聚合。