7

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.

ddv
  • 135
  • 2
  • 6

2 Answers2

6

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

xhafan
  • 2,140
  • 1
  • 26
  • 26
  • Just recently read [Effective Aggregate Design](https://vaughnvernon.co/?p=139) 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) – xhafan Jul 26 '13 at 08:03
  • Fixed the link to [Effective Aggregate Design](http://dddcommunity.org/library/vernon_2011) – xhafan Jul 15 '15 at 07:47
  • 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). – plalx Aug 17 '15 at 14:17
  • 1
    @xhafan 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 :-) – user1016265 Mar 09 '16 at 11:12
  • @user1016265 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. – xhafan Mar 21 '16 at 07:57
  • 1
    @xhafan 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``` ?? – user1016265 Mar 22 '16 at 20:24
  • 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: https://github.com/jagregory/fluent-nhibernate/wiki/Auto-mapping ,and here: https://github.com/jagregory/fluent-nhibernate/tree/master/src/Examples.FirstAutomappedProject how to use it – xhafan Mar 23 '16 at 09:21
5

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.

Eben Roux
  • 12,983
  • 2
  • 27
  • 48
  • 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_. – ddv Dec 05 '12 at 03:21
  • 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 – ddv Dec 05 '12 at 03:33
  • 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. – Eben Roux Dec 05 '12 at 04:17