在DDD中，具有深层次结构的聚合根是否合适？ [英] Is Aggregate Root with Deep Hierarchy appropriate in DDD?

问题描述

我有一个系统，用户可以用表格回答问题。我有代表此模型的对象，但我不太确定如何根据DDD组织这些对象。

I have a system where a user answers question in a form. I have objects representing this model but I am not quite sure how to organize these objects in terms of DDD.

1. 表格（具有其自己的列表）；


2. Section->（具有其自己的列表）组列表；


3. 组->（具有自己的问题列表）


4. 问题->（可以具有自己的子列表） -questions）问题；


5. 问题->（有其自己的列表）；


6. 答案->（有其自己的列表）Answer_Details ;


7. Answer_Detail->（可能具有自己的子详细信息列表）Sub_Answer_Details。

1. Form (has its own list of) Sections;
2. Section -> (has its own list of) Groups;
3. Group -> (has its own list of) Questions;
4. Question ->(can have its own list of sub-questions) Questions;
5. Question -> (has its own list of) Answers;
6. Answer -> (has its own list of) Answer_Details;
7. Answer_Detail -> (potentially has its own list of sub details) Sub_Answer_Details.

每个对象都有15个以上的属性，没有父属性就没有意义。根据DDD，我认为Form实体应该是一个聚合根，而所有其他对象都应该是值对象。这意味着我只需要一个用于Form实体的存储库。在这种情况下，FormRepository会充斥各种子对象的CRUD方法。我在DDD方面的推理正确吗？可以，我最终得到非常广泛的汇总吗？我相信这种表示形式很容易导致性能问题。

Every object has more than 15 properties and each doesn't make sense without its parent. According to DDD, I believe that Form entity should be an Aggregate Root and all other objects should be value objects. That means I need a Repository only for Form entity. In this case FormRepository will be cluttered with all kinds of CRUD methods for child objects. Is my reasoning right in terms of DDD? Is that OK that I end up with a very extensive aggregate? I believe such representation can easily lead to performance issues.

推荐答案

是的，在DDD中可以使用深层次结构。

Yes, deep hierarchy is fine in DDD.

我可以接受非常广泛的汇总吗？-如果现实是如此复杂，并且您的域模型是最好的如您所知，最终将得到一个复杂的汇总根。

Is that OK that I end up with a very extensive aggregate? - if the reality is that complex, and your domain model is as best as you can figure out, you will end up with a complex aggregate root.

是，表格应该汇总根。

所有其他对象应为值对象-错误，所有其他对象应为非集合根实体（带有ID），且不带存储库以获取它们。值对象没有ID，值对象的相等性仅由其属性值确定，而不由ID的相等性决定（更多信息此处）。

all other objects should be value objects - wrong, all other objects should be non-aggregate root entities (with Id) without a repository to fetch them. Value object does not have an Id, and an equality of value objects is determined only by its attribute values, not by equality of Ids (more info here).

在此情况下，FormRepository会充斥各种针对子对象的CRUD方法-不，存储库应仅包含有关聚合根的方法，即 Get< T ，保存< T>其中T：IAggregateRoot ，一旦获得聚合根实例，就可以遍历属性和方法以获取所需的内容。示例：

In this case FormRepository will be cluttered with all kinds of CRUD methods for child objects - no, a repository should contain only methods regarding aggregate root, i.e. Get<T> , Save<T> where T : IAggregateRoot, once you get an instance of an aggregate root, you can traverse via attributes and methods to get what you need. Example:

var formId = 23;
var form = _formRepository.Get(formId);
var firstGroup = form.Sections.First().Group().First();

或更佳

var groupIndex = 1;
var firstGroup = form.GetGroupAt(groupIndex);

其中

public Group GetGroupAt(int groupIndex)
{
    Sections.First().Group().ElementAt(groupIndex);
}

我相信这样的表示很容易导致性能问题-如果您使用 CQRS ，则将调用某些表格域方法（如果您使用NHibernate进行实体持久化），则默认情况下将使用延迟加载，并且仅从数据库中加载 Form ，并且那么它将仅加载您真正接触过的实体，例如， Sections.First（）将从数据库加载所有节，但不加载组和其余部分。对于查询，您将创建一个 FormDto （数据传输对象）和其他可能扁平化的dto，以获取所需形式的数据（这可能与您的实体结构和UI不同可能会驱动dto结构）。看看我的博客获取有关DDD / CQRS / NHibernate /存储库的信息

I believe such representation can easily lead to performance issues - if you use CQRS, you gonna be calling some Form domain method from command handler, and if you use NHibernate for entity persistence, it will by default use lazy loading, and would load only Form from DB, and then it would load only entities you really touch, so for instance Sections.First() would load all sections from DB, but not groups and the rest. For querying, you would create a FormDto (data transfer object) and other possibly flattened dtos to get data in the form you need (which might be different from your entities structure and UI might drive the dto structure). Have a look at my blog for info regarding DDD/CQRS/NHibernate/Repository

这篇关于在DDD中，具有深层次结构的聚合根是否合适？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！