DDD聚合根/存储库结构

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将具有标识,可以引导您创建单独的存储库.