repository - DDD 聚合根/存储库结构

Question

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

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

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

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

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

Answer 1

我认为 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的初始化类(class)应由 PersonFactory 处理.
PersonFactory是服务，所以可以引用 AccountTypeRepository寻找合适的 AccountType实例并返回该类型的完全构造的 Person 实例。

更新:另外我想添加一个注释 referencing your AccountType by id效果同样好。这一切都是为了方便，有时如果您使用具有丰富数据绑定(bind)功能(如 WPF 或 Spring MVC)的 GUI 框架，则直接访问引用更方便(当然，仅用于显示，而不是用于修改)，因此您可以直接访问此属性以显示在 View 中。如果您使用 id 方法，这可能会迫使您创建 ViewModels (FormBeans)，即使是简单的实体也是如此。

关于 lookup-based solution ，它适用于非常简单的类似枚举的字段，我想 AccountType比这更复杂，属于知识级别(参见问题的讨论)。

回到聚合和值对象之间的选择(另见 this )，这取决于您的信息系统的抽象级别和配置能力。
从 Account的角度来看class 它可能看起来像一个值对象，你可以替换一个 AccountType另一个:这就像在颜色值对象之间切换一样，但是从知识水平的角度来看，您的用户可能希望为选定的 AccountType 自定义系统的行为，例如更改特定“Premium”帐户的折扣。所以如果你有知识水平， AccountType将是具有身份的东西，它会引导您创建一个单独的存储库。