DDD聚合根/存储库结构

Question

我是新手,所以我的理解仍然不明确.

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

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

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

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

Answer 1

我认为AccountType这是从Person聚合根引用的另一个聚合根.有许多简单的聚合根是绝对正常的,参见Vaughn Vernon的文章,见第1部分,p.5:

在使用[Qi4j]的金融衍生产品部门的一个项目中,Niclas [Hedhman]报告说他的团队能够设计大约70%的聚合,只有一个包含一些价值类型属性的根实体.剩下的30%只有两到三个实体.这并不表示所有域模型都具有70/30分割.它确实表明高比例的聚合可以限于单个实体,即根.

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

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

Person应该通过处理类的初始化PersonFactory.

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

更新:此外,我还想添加一个注释,通过id引用您的AccountType同样有效.这是方便的问题,如果您使用具有丰富数据绑定功能的GUI框架(如WPF或Spring MVC),有时更方便(仅用于显示,而不是用于修改)直接访问引用,因此您可以直接访问此属性在视图中显示.如果您使用id方法,这可能会迫使您创建ViewModels(FormBeans),即使对于简单的实体也是如此.

关于基于查找的解决方案,它适用于非常简单的类似枚举的字段,我认为这AccountType是比这更复杂的东西,属于知识级别(参见问题的讨论).

回到聚集和值对象(也见之间选择这个),这取决于你的信息系统的抽象水平和配置能力.从类的角度来看,Account它可能看起来像一个值对象,你可以AccountType用另一个替换:它就像在Color值对象之间切换一样,但是从知识层面来看,你的用户可能想要自定义行为选定AccountType的系统,例如更改特定"高级"帐户的折扣.因此,如果您具有知识级别,那么AccountType将使用具有标识的内容来引导您创建单独的存储库.