从 DDD 的角度来看，我可以拥有非聚合根的存储库吗
From DDD perspective can I have repository for non-aggregate-root
在我当前的 (JPA) 项目中，我基本上有 2 个实体。 ChainOfClassesA 和 ClassA。现在 ChainOfClassesA 基本上是 ClassA (@OneToMany) 和其他几个属性的双向列表。对我来说，ChainOfClassesA 似乎是一个聚合根，因此具有专用的存储库。现在，一个用例是更新 ClassA。我知道我可以为 ClassA 创建存储库，但这会违反规则 "one repository for each root aggregate entity"，因为 ClassA 并不是真正的聚合根，尽管这暗示我它可能是，或者我应该 "flatten ChainOfClassesA"。
现在我的问题是，我应该务实 "just break the rules" 并为 ClassA 创建专用存储库，还是遵循规则将 ChainOfClassesA 中的双向列表 @OneToMany 替换为 ClassA 中 ChainOfClassesA 的 ID 引用。第一种方法是实用的，只需要很少的工作，而后一种方法还需要对代码库进行一些其他更改。你觉得呢？你有没有什么想法？特别是为什么我不应该为非聚合根创建存储库（除非那个人可能会使用该存储库以便不再满足事务边界）
如果 ChainOfClassesA 是一个聚合根并且它有一个 ClassA 的集合。如果您需要一个用例来更新 ClassA，您可以在 ChainOfClassesA 对象上定义一个方法。我看不出 ClassA 有任何理由引用 ChainOfClassesA，因为无论如何它只能在 ChainOfClassesA 的范围内使用。如果 EF 允许您这样做，则没有必要意味着您应该这样做。如果您为每个 ClassA 定义一个 repo，则意味着它可以完全独立于自己的生命周期。并且所有其他聚合最终都与它一致。如果去掉ChainOfClassesA，ClassA是不是还要继续活下去？如果是，那么ClassA可能应该是一个单独的集合。
在我当前的 (JPA) 项目中，我基本上有 2 个实体。 ChainOfClassesA 和 ClassA。现在 ChainOfClassesA 基本上是 ClassA (@OneToMany) 和其他几个属性的双向列表。对我来说，ChainOfClassesA 似乎是一个聚合根，因此具有专用的存储库。现在，一个用例是更新 ClassA。我知道我可以为 ClassA 创建存储库，但这会违反规则 "one repository for each root aggregate entity"，因为 ClassA 并不是真正的聚合根，尽管这暗示我它可能是，或者我应该 "flatten ChainOfClassesA"。
现在我的问题是，我应该务实 "just break the rules" 并为 ClassA 创建专用存储库，还是遵循规则将 ChainOfClassesA 中的双向列表 @OneToMany 替换为 ClassA 中 ChainOfClassesA 的 ID 引用。第一种方法是实用的，只需要很少的工作，而后一种方法还需要对代码库进行一些其他更改。你觉得呢？你有没有什么想法？特别是为什么我不应该为非聚合根创建存储库（除非那个人可能会使用该存储库以便不再满足事务边界）
如果 ChainOfClassesA 是一个聚合根并且它有一个 ClassA 的集合。如果您需要一个用例来更新 ClassA，您可以在 ChainOfClassesA 对象上定义一个方法。我看不出 ClassA 有任何理由引用 ChainOfClassesA，因为无论如何它只能在 ChainOfClassesA 的范围内使用。如果 EF 允许您这样做，则没有必要意味着您应该这样做。如果您为每个 ClassA 定义一个 repo，则意味着它可以完全独立于自己的生命周期。并且所有其他聚合最终都与它一致。如果去掉ChainOfClassesA，ClassA是不是还要继续活下去？如果是，那么ClassA可能应该是一个单独的集合。