DDD汇总根/存储库结构

本文介绍了DDD汇总根/存储库结构的处理方法，对大家解决问题具有一定的参考价值，需要的朋友们下面随着小编来一起学习吧！ 问题描述

我对此并不陌生，所以我的理解仍然很薄弱.

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

现在，如果我的理解是正确的，那么Person绝对是一个聚合根，而AccountType可能不是，因为Account type表中的条目将几乎是静态的，并且在Person之外毫无意义.

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

构造这个的正确方法是什么?

我认为 AccountType 是另一个从 Person 聚合根引用的聚合根.具有许多简单的聚合根绝对是正常的，请参见沃恩·弗农(Vaughn Vernon)文章，请参见第1部分，第1页.5 :

在一个金融衍生品行业的项目中，使用[Qi4j]，Niclas [Hedhman]报告说，他的团队能够仅用一个设计就可以设计大约70％的骨料包含一些值类型属性的根实体.其余30％的实体总共只有2到3个.这并不表示所有领域模型都会有70/30的分割比例.它确实表明高比例的骨料可以限于单个实体，即根.

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

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

Person 类的初始化应由 PersonFactory 处理.

PersonFactory 是一项服务，因此它可以引用 AccountTypeRepository 来找到合适的 AccountType 实例并返回完全构造的Person实例.这种类型的.

更新:我还要添加一条说明，即通过ID引用您的AccountType 效果也不错.一切都很方便，有时，如果您使用具有丰富数据绑定功能的GUI框架(例如WPF或Spring MVC)，则直接访问引用更方便(当然，仅用于显示，而不是用于修改)，因此您可以直接访问此属性以在视图中显示.如果您使用id方法，那么即使是简单的Entities，也可能会迫使您创建ViewModels(FormBeans).关于基于查找的解决方案，它非常适用于非常简单的枚举式字段，我想 AccountType 比这更复杂，并且属于知识级别(请参阅问题的讨论).

返回汇总和值对象之间的选择(另请参见此)，这取决于您的信息系统的抽象级别和配置功能.从 Account 类的角度看，它看起来像是一个值对象，您可以将其中一个 AccountType 替换为另一个:这就像在Color值对象之间切换一样，但从知识水平的角度来看，您的用户可能希望针对所选AccountType自定义系统的行为，例如，更改特定"Premium"帐户的折扣.因此，如果您具有知识水平， AccountType 将具有某种身份，可以使您创建一个单独的存储库.

I am new to this, so my understanding is still flaky.

I have a Person model and an AccountType model in my project. Each person references an account type.

Now if my understanding is correct a Person is definitely an aggregate root, whereas the AccountType probably isn't as the entries in the account type table are going to be pretty much static and are certainly have no meaning outside of a Person.

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.

What would be the correct way to structure this?

解决方案

I think that AccountType is another aggregate root which is referenced from the Person aggregate root. It's absolutely normal to have many simple aggregate roots, see Vaughn Vernon articles, see 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.

In your question it's not quite understood, what is the problem with accessing repositories to initialize the aggregate root's properties:

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.

The initialization of the Person class should be handled by PersonFactory.

The PersonFactory is a service, so it can have reference to AccountTypeRepository to find a suitable AccountType instance and return a fully constructed Person instance of that type.

update: Also I'd like to add a note that referencing your AccountType by id works equally well. It's all matter of convenience, sometimes it's more convenient(only for displaying, not for modifying, of course) to access the references directly if you use GUI frameworks with rich data binding capabilities like WPF or Spring MVC so you can directly access this properties to display in View. If you are using the id approach, this may force you to create ViewModels (FormBeans) even for the simple Entities. Regarding the lookup-based solution, it works well for very simple enum-like fields, I suppose that AccountType is something more complex than that and belongs to the knowledge level (see the discussion of the question).

Returning to the choice between aggregates and value object(also see this), it depends on the abstraction level and configuration capabilities of your information system. From the point of view of the Account class it may look like a value object, you can replace one AccountType with another: it will be just like switching between Color value objects, but from the point of the knowledge level your user may want to customize the behavior of the system for selected AccountType, for example change discounts for specific "Premium" accounts. So if you have the knowledge level, AccountType will be something with an identity which leads you to creating a separate repository.