Does it make sense to make this aggregate roots design?

Question

Let's assume a project presenting those specifications:

• Each Employee can organize a Meeting inviting other Employees.
• Each Employee can accept the invitation to participate to the Meeting, while the number of max Participations isn't exceeded.
• Any Manager of the Employee creator can cancel the Meeting at any time.

IMO, the invariants are:

• A Meeting exists as long as the creator (Employee) exists (not deleted or flag as deleted).
• There shouldn't be at any time a Meeting containing a number of participants superior to the limite intended.
• Any Employee that cancels its created Meeting should have also this Participations canceled /deleted.
• When a Manager cancels an Employee's Meeting, both the Meeting and the Participations should be deleted.

Should I make:

• the Employee an Aggregate Root, containing the collection of its created Meetings.
• Meeting being thus an inner entity of Employee and containing a collection of Participations.
• Manager as the other Aggregate Root, containing a collection of its Employees.

Thus there would be just to Aggregate Roots: Employee and Manager.
Indeed, a Manager could be fired and then is not part of an invariant with the Employee, and vice versa.

In details:
_ Employee would provide a method createParticipation, encapsulating checks for the important rules like whether the number max of participants is exceeded.
_ Employee would provide also a Factory to create Meeting, allowing to always assign the correct EmployeeId to the Meeting.
_ Only two repositories would be created: EmployeeRepository and ManagerRepository, avoiding direct access to respective inner parts.
(that deals only with creations, deletions would be similar)

Therefore, in order to create a Meeting's Participation, my entry point would be the creator(Employee) that I retrieve through the EmployeeRepository.

Does it make sense in order to follow strict DDD practice?

Answer 1

Your Employee aggregate is way too big. This creates concurrency issues. What would happen if two employees accept the invitation in the same time? One transaction would be rolled back because they try to modify the same aggregate. Unless you designed some fancy conflict resolution logic.

Instead, consider Participation and Meeting to be separate aggregates.