Domain-Driven Design – Why Aren’t Entities Allowed to Reference Other Entities Inside an Aggregate Except the Root?

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.

You need to understand that DDD is not about primary keys, rows or tables - these are just means to implement it.

Aggregate root is usually implemented as a class, because you are expected to access all the functionality and data of the aggregate through the root. It therefore needs to have some behavior, something which primary key of the table can't have. Primary benefit of this is the encapsulation of aggregates - its logic is completely contained inside the aggregate and doesn't leak outside which greatly reduces the coupling (and as a consequence complexity) of the application.

It follows that each aggregate has its own aggregate root, so two aggregates can't have the same root (if they have, there is effectively just one aggregate).

In your case, you probably want to have two independent aggregates (ActiveEmployee, InactiveEmployee) which are backed by the same table (which is fine because it's totally out of DDD's scope). But then remember that there's actually no dbo.Employee entity in your domain model, it's just a table on a lower (persistence) layer.