从DDD角度来看,我可以为非聚合根用户提供存储库吗?

时间:2019-01-25 15:06:46

标签: domain-driven-design ddd-repositories

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

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

1 个答案:

答案 0 :(得分:1)

如果ChainOfClassesA是一个聚合根,并且它具有ClassA的集合。如果需要用例来更新ClassA,则可以在ChainOfClassesA对象上定义一个方法。我没有看到ClassA引用ChainOfClassesA的任何理由,因为它只能在ChainOfClassesA的范围内使用。如果EF允许您执行此操作,则没有必要意味着您应该执行此操作。如果您为每个ClassA定义一个仓库,则意味着它可以与自己的生命周期完全分开。所有其他集合最终都与之保持一致。如果删除ChainOfClassesA,ClassA是否应该继续存在?如果是,则ClassA可能应该是单独的集合。