DDD聚合根/存储库结构

Question

我是新手，所以我的理解仍然不稳定。

我的项目中有Person模型和AccountType模型。每个人都引用了一种帐户类型。

现在，如果我的理解是正确的，那么Person肯定是一个聚合根，而AccountType可能不是因为帐户类型表中的条目几乎是静态的，并且在Person之外肯定没有任何意义。

然而，当我创建一个新人时，我需要设置帐户类型，因此我似乎需要一个存储库来访问要分配给用户的帐户类型，但我只能访问存储库代码来访问聚合根

构建这个的正确方法是什么？

Answer 1

我认为AccountType是另一个从Person聚合根引用的聚合根。 拥有许多简单的聚合根是绝对正常的，请参阅Vaughn Vernon articles，参见part 1, p. 5：

  

关于金融衍生品行业的一个项目   [Qi4j]，Niclas [Hedhman]报道说他的团队能够   只用a设计大约70％的聚合   包含一些值类型属性的根实体。剩下的30％只有两到三个实体。这并不表示所有域模型都将具有70/30分割。它   确实表明聚合物的比例很高   限于单个实体，根。

在你的问题中，它还不太清楚，访问存储库以初始化聚合根的属性有什么问题：

  

然而，当我创建一个新人时，我需要设置帐户类型，因此我似乎需要一个存储库来访问要分配给用户的帐户类型，但我只能访问存储库代码来访问聚合根

Person类的初始化应由PersonFactory处理。

PersonFactory是一项服务，因此它可以引用AccountTypeRepository来查找合适的AccountType实例，并返回该类型的完全构造的Person实例。

更新：另外，我想添加referencing your AccountType by id同样有效的说明。这是方便的问题，如果您使用具有丰富数据绑定功能的GUI框架（如WPF或Spring MVC），有时更方便（仅用于显示，而不是用于修改）直接访问引用，因此您可以直接访问此属性在视图中显示。如果您使用id方法，这可能会迫使您创建ViewModels（FormBeans），即使对于简单的实体也是如此。

<小时/> 关于lookup-based solution，它适用于非常简单的枚举字段，我认为AccountType比这更复杂，属于知识层面（参见问题的讨论）。

返回聚合和值对象之间的选择（另请参阅this），它取决于信息系统的抽象级别和配置功能。 从Account类的角度来看，它可能看起来像一个值对象，你可以将一个AccountType替换为另一个：它就像在Color值对象之间切换一样，但是从知识级别您的用户可能希望自定义所选AccountType的系统行为，例如更改特定“Premium”帐户的折扣。因此，如果您具有知识级别，AccountType将具有标识的内容，这将导致您创建单独的存储库。

Answer 2

最重要的是（假设AccountType有一个带有ID且不是简单枚举的实体）......

帐户类型和人员只应按ID引用。