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.

Answer 1

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.

Answer 2

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