6

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

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

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

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

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

4

2 回答 2

11

我认为AccountType这是从聚合根引用的另一个聚合Person根。有许多简单的聚合根是绝对正常的，请参阅Vaughn Vernon 的文章，请参阅第 1 部分，第 1 页。5：

在一个使用 [Qi4j] 的金融衍生品行业项目中，Niclas [Hedhman] 报告说，他的团队能够设计大约 70% 的聚合，其中仅包含一些值类型属性的根实体。剩下的 30% 总共只有两到三个实体。这并不表示所有域模型都会有 70/30 的拆分。它确实表明高百分比的聚合可以限制为单个实体，即根。

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

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

类的初始化Person应该由PersonFactory.

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

更新：我还想补充一点，通过 id 引用您的 AccountType也同样有效。这一切都是为了方便，有时如果您使用具有丰富数据绑定功能（如 WPF 或 Spring MVC）的 GUI 框架，则直接访问引用更方便（当然，仅用于显示，而不是用于修改），因此您可以直接访问此属性以显示在视图中。如果您使用 id 方法，这可能会迫使您创建 ViewModels (FormBeans)，即使是简单的实体也是如此。

关于基于查找的解决方案，它适用于非常简单的类似枚举的字段，我认为这AccountType比这更复杂，属于知识级别（参见问题的讨论）。

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

于 2012-08-07T12:11:02.740 回答
2

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

Account Type 和 Person 只能通过 ID 相互引用。

于 2012-08-08T14:45:31.837 回答