我的项目中有Person模型和AccountType模型.每个人都引用一种帐户类型.
现在,如果我的理解是正确的,那么Person绝对是一个聚合根,而AccountType可能不是因为帐户类型表中的条目几乎是静态的,并且在Person之外肯定没有任何意义.
但是,当我创建一个新人时,我需要设置帐户类型,因此我需要一个存储库来访问要分配给用户的帐户类型,但我只能访问存储库代码来访问聚合根.
构建这个的正确方法是什么？
我认为AccountType是从Person聚合根引用的另一个聚合根.有许多简单的聚合根是绝对正常的,见 Vaughn Vernon articles,见 part 1, p. 5：
On one project for the financial derivatives sector using
[Qi4j], Niclas [Hedhman] reported that his team was able to
design approximately 70% of all aggregates with just a
root entity containing some value-typed properties. The remaining 30% had just two to three total entities. This doesn’t indicate that all domain models will have a 70/30 split. It
does indicate that a high percentage of aggregates can be
limited to a single entity, the root.
在您的问题中,它还不太清楚,访问存储库以初始化聚合根的属性有什么问题：
However when I create a new person I need to set the account type, so it would seem I need a repository to access the account type to assign to the user, but the repository code I have only allows aggregate roots to be accessed.
Person类的初始化应该由PersonFactory处理.
PersonFactory是一个服务,因此它可以引用AccountTypeRepository来查找合适的AccountType实例并返回该类型的完全构造的Person实例.
更新：另外我想补充说明referencing your AccountType by id同样有效.这是方便的问题,如果您使用具有丰富数据绑定功能的GUI框架(如WPF或Spring MVC),有时更方便(仅用于显示,而不是用于修改)直接访问引用,因此您可以直接访问此属性在视图中显示.如果您使用id方法,这可能会迫使您创建ViewModels(FormBeans),即使对于简单的实体也是如此.
关于lookup-based solution,它适用于非常简单的类似enum的字段,我认为AccountType比这更复杂,属于知识级别(参见问题的讨论).
回到聚合和值对象之间的选择(也见this),它取决于信息系统的抽象级别和配置功能.从Account类的角度来看,它可能看起来像一个值对象,您可以将一个AccountType替换为另一个：它就像在Color值对象之间切换一样,但是从用户可能想要定制的知识级别的角度来看系统对所选AccountType的行为,例如更改特定“Premium”帐户的折扣.因此,如果您具有知识级别,则AccountType将具有标识,可以引导您创建单独的存储库.