在聚合根和实体中使用引用的最佳实践

时间:2017-11-04 09:37:02

标签: domain-driven-design aggregateroot

让我说我有

  • 聚合根A,其中包含实体B

  • 聚合根C,其具有实体D

我已经读过,最佳做法是将对象ID保存在聚合根中,而不是直接引用,例如A-> C_Id和C-> A_Id。

  • 可以在单独的聚合中聚合实体的持有ID吗?像A-> D_Id和C-> B_Id?
  • 一个聚合根可以实例化另一个聚合根吗?像A实例C一样,反之亦然?
  • 可以聚合A实例化存储在单独聚合中的实体的新实例吗?像A试图实例化D或C尝试实例化B?
  • 可以将聚合和/或实体方法作为参数直接引用其他聚合中的实体,前提是它们在方法退出后不会存储直接引用吗?类似于A->方法(D)或B->方法(C)

3 个答案:

答案 0 :(得分:0)

是的:)

没有任何理由可以解释为什么你的选择不正确。

  

可以在单独的聚合中聚合实体的持有ID吗?像A-> D_Id和C-> B_Id?

如果存在真正的关系,那么这肯定是可能的。

  

一个聚合根可以实例化另一个聚合根吗?像A实例C一样,反之亦然?

让一个聚合物作为另一个聚合物的工厂是绝对没问题的。通常,这需要两者都在相同的有界上下文中。

  

可以聚合A实例化存储在单独聚合中的实体的新实例吗?像A试图实例化D或C尝试实例化B?

与上述相同。

  

聚合和/或实体方法可以将实体与其他聚合的直接引用作为参数,前提是它们在方法退出后不会存储直接引用吗?类似于A->方法(D)或B->方法(C)

这是完全合理的,但是,当实体处于相同的有界上下文中时,这可能只是可行的。话虽如此,很有可能使用一个值对象来表示来自另一个BC的聚合作为该实例。

答案 1 :(得分:0)

  

我已经读过,最佳做法是将对象ID保存在聚合根中,而不是直接引用,例如A-> C_Id和C-> A_Id。

是的,这是推荐的方式。

  

可以在单独的聚合中聚合实体的持有ID吗?像A-> D_Id和C-> B_Id?

是的,但只是在阅读方(即用户界面)上使用该信息,而不是用它来保护不变量。

  

一个聚合根可以实例化另一个聚合根吗?像A实例C一样,反之亦然?

我不推荐它。汇总A将承担很多责任。此外,聚合应该彼此独立。

  

可以聚合A实例化存储在单独聚合中的实体的新实例吗?像A试图实例化D或C尝试实例化B?

在任何情况下。这将打破其他聚合的封装。

  

聚合和/或实体方法可以将实体与其他聚合的直接引用作为参数,前提是它们在方法退出后不会存储直接引用吗?类似于A->方法(D)或B->方法(C)

我不推荐它,因为它会与两个聚合物耦合。相反,您应该传递基元或值对象。

答案 2 :(得分:0)

  

可以在单独的聚合中聚合实体的持有ID吗?像A-> D_Id   和C-> B_Id?

你的意思是非根实体?只是一个ID通常没有任何帮助,因为非AR实体无法通过存储库直接检索。您必须存储实体ID及其父聚合根ID。记住关于另一个聚合体内部的太多东西也可能是代码味道。

  

一个聚合根可以实例化另一个聚合根吗?像一个   实例化C,反之亦然?

不确定。在某些approaches中,它甚至是建议创建AR的方法。

  

可以聚合A实例化存储在其中的实体的新实例   单独的聚合?像A尝试实例化D或C尝试   实例化B?

为什么不呢,虽然我现在无法想到一个有效的例子,除了简单的价值对象。你有一个想法吗?

  

聚合和/或实体方法可以直接作为参数   来自其他聚合的实体的引用,只要它们会   方法退出后不存储直接引用?像A->方法(D)或   B->方法(C)

是的,瞬态参考是好的。