How do I define aggregate and aggregate roots and link between aggregates

Question

So I am new to DDD and I am trying to design an application correctly. But I am having a bit of difficulty with identifying aggregate roots.

My need is more or less a tree

*Customers
*Each customer can have 0 or more licenses
*Each license can have 0 or more courses
*Each course can have 0 or more lessons
*Each lesson can have 0 or more slides and videos

Finally I have quizzes/tests that can be linked to almost anything, even a certain time in a video in a lesson.

No matter how I think about it I only get that Customer will be an aggregate root for an aggregate that contains [Customer, License, Course, Lesson, Slide, Video]

But that is a fairly big aggregate and I have understood that big aggregates should be avoided.

A quiz would then be an aggregate with questions, answers and so on. As a second question I might ask is how the link should look? because lets say i want a quiz to pop up in a video after 4 minutes. Well then my quiz needs to link to that video and store a time. But that video is deep down another aggregate (under customer, license, course, lesson) and should not be linked directly in a persistent way from this quiz aggregate.

So how do I solve that. I have ordered my big DDD book but it wont be here for a while, If I could understand this before then it would be great!

I dont it should matter but I use .net c# mvc, with ef5 and repository pattern.

Answer 1

In order to simplify things you should use CQRS i.e use different models for 'writing' and for querying. This means we have 2 cases 1. creating and updating business objects (entities) 2. generating a simplified model from the business objects to allow simple querying

Using this approach means that you can focus on modelling the Customer, License, Course ,Lessons strictly for the purpsoe of modelling the real behaviour and relations between them.

It's easy here to fall in the data centric approach, where a Customer is viewed as a container for licenses which in turn are a container for courses etc. It's pretty obvious (even without much information) that these entities are aggregate roots but not containers.

It might be more suitable the to think lessons are organized into courses which are organized according to licences. This means that the Course entity is associated with some Lesson entities, so the Course actualy doesn't have Lessons. It has the a name, a syllabus etc. Lessons, Professors , Students are 'attached' to a Course but not part of it.

A Customer entity models a customer. When a customer buys some licenses, then (s)he gets the right to access the courses associated with that license. Once again, the Customer doesn't have the licenses.So here you need to model the associations between a customer and the licences. When doing that, think what details of LIcense depends on what detail of Customer (chances are they don't, as they are quite different things so a basic (CustomerId,LicenseId) is enough). Of course, these are simple suggestions as I don't know exactly the domain.

The main point is that you have to delve deeper into understanding what Customer, License etc means for the domain and resist the urge to view things the 'obvious' way. DDD modelling is not hard but it's very tricky because you really must not be superficial about it.

Answer 2

You should define aggregates after business invariants.

Take a loot at the Vernon's essay on aggregate design.
To relate different aggregates you can use shared identifiers, that also remove the need for lazy loading.

However you should also consider if you have to design different bounded contexts. Talk with your domain expert(s), explaining that each bounded context relates to a specific point of view over the matter.