Can an aggregate root hold references of members of another aggregate root

aggregatedomain-driven-designuml

I know that outside of aggregates I can't change anything inside an aggregate without passing by his root. That said I would like to know if an aggregate root can hold references of members (objects insides) of another aggregate root? (following DDD rules)

Example :

a Calendar contain a list of phases which contain a list of sequences which contain a list of assignations

Calendar is root because phases and sequences and assignations only work in context of a calendar.

You also have Students and Groups of student (called groups)

It is possible (following DDD rules) to make Groups holding references of assignations or it need to pass by the root for accessing groups from assignations ?

Thanks.

Best Answer

If I understand your question correctly, you are asking about the basics of UML class diagrams?

Would like to know if its possible to hold multiple references of an aggregate root (groups) inside another aggregate root (calendar) member ?

Classes can be associated with any other classes, in any way they want. That's the whole purpose of designing a system.

Also how a list of references are represented in UML ? it is a simple relation ?

A list of references can either be aggregation (has a) or composition (owns a).

But assignations must hold multiple references to groups of students. (Must work two sides)

This isn't really clear, you are talking about a bidirectional relation between groups and students? In any case, perhaps this article on many to many relations can provide you with some insight.

If there was no such thing as “student”, would there be meaning to “student group” ? Probably not. If there was no such thing as “student group”, would there be meaning to “student” ? Probably.

UPDATE:

It is possible (fellowing DDD rules) to make Groups holding references of assignations or it need to pass by the root for accessing groups from assignations ?

I never modelled a system with DDD in mind, but by reading the previously mentioned article. I would say, try to prevent it when not necessary, if there are no performance issues, access the groups through assignations. That is, if that's the correctly chosen aggregate root.

Apply the "student, student group" example to all your elements to choose the correct aggregate roots.