Is Aggregate Root with Deep Hierarchy appropriate in DDD?

Question

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. 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.

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.

Barta

Answer 1

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.

Yep, Form should be aggregate root.

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).

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();

or better

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

where

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

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

Rumph

Just recently read Effective Aggregate Design where small aggregates are recommended. There might be performance problems with a huge aggregate which contains a collection of child entities with like thousands items, because adding an item to the collection is fetching the whole collection (e.g. nhibernate works like this) – Rumph

Fixed the link to Effective Aggregate Design – Rumph

It depends on many factors. Will there be concurrent modifications of the same form? If the answer is yes then you shouldn't create a larger cluster aggregate. Also, your use case is very CRUD so from your UI perspective I guess you just present all editable fields for the entire form and save that as an entire document. However, if your UI was a bit more segregated (e.g. allowing to edit a single group at a time, or a single section, etc. then you would benefit from having multiple AR's). – Neace

@Rumph What do you think about storing such big AR with all child entities, should these methods placed in the same repository ? Just imagine that topic starter has a RDBMS for each entity he has own table, it's clear that no one except AR repository should able to store them, but in that case Repository will looks like a hell :-) – Aleasealeatory

@Aleasealeatory I don't really understand what you are asking. In my view a repository should be simple, and have just Get, Save and Delete methods, nothing else. – Rumph

@Rumph Repository should store an Aggregate Root. If AR will be quite complicated then own repository has to save all these entities (sometime) in different tables. Even with Order/OrderLine. With RDBMS it might be at least two different tables, will you put all this into one save method, or you will have a private method saveOrderLine ?? – Aleasealeatory

aaa ok. I use nhibernate for persistence, so to save AR, you call session.Save(aggregateRoot); and that's all, it will persist the whole tree into their tables. Have a look here: github.com/jagregory/fluent-nhibernate/wiki/Auto-mapping ,and here: github.com/jagregory/fluent-nhibernate/tree/master/src/… how to use it – Rumph

Answer 2

Even though an answer has been accepted I thought I may as well add my 2 cents:

Deep hierarchies are (probably) fine but remember that the idea behind an aggregate is to actually prevent this. I tend to think of entities in an aggregate along the lines of:

"Does this entity have any meaning without the AR?"

Since I do not have any context w.r.t. your model I will use Order/OrderLine. Does an OrderLine have any meaning without the Order? Can I do anything (behaviour) with the order line by itself? The obvious answer here is "no".

Each model will need to be treated based on the context. But ownership does not necessarily mean containment.

These may be easier to see when you work with separate bounded contexts provided one gets the BCs correct :)

In your case an Answer may have no meaning without its Question. But maybe a Question can live in a QuestionBank BC and a particular question may be used in both your Examination BC and your Enrollment BC. All these are totally made up so it would depend on your context.

So if it is a case that Question can be an AR then the questions that are owned by your Form AR may simply be a Value Object or even a simple QuestionId.

Olivette

Thank you for your 2 cents. I don't quite understand what you mean by: So if it is a case that Question can be an AR then the questions that are owned by your Form AR may simply be a Value Object. – Barta

How Question being an AR can be a Value Object. All AR should be Entities. Actually in my case all objects don't make sense without an owner. They are not accessed without Form context. Sections and Groups in my case don't have other meaning than grouping questions. Please, let me know if you approach would be different from @xhafan's one. What objects do you think can be VOs – Barta

Ah, I see why may answer may not make sense :) --- sorry about that. What I mean is that if an AR in BC-A is used in BC-B then in BC-B you could use either just the relevant AR Id or model it as a Value Object. The model would depend 100% on your context / understanding of the model. So I cannot say, for certain, that what you have is not correct. I have, however, modelled ARs in a similar fashion in the past and, in hindsight, I know it was not 100% correct. If it works then it is fine; if you run into issues/duplication you'll want to look at the model again. – Olivette