DDD: Can an Aggregate Root be an Entity within another Aggregate Root?

Question

I'm trying to model a problem where a Company has many Teams. There is a business rule that "the name of the team must be unique per company". However, a Team has many other behaviours, such as joining. Also, a Team can have many Reports - which maintain a reference to Team.Id.

At the moment, Team and Company are separate Aggregate Roots. In order to enforce the invariant that Team.Name must be unique per Company, should I could create a Team Entity within the Company Aggregate which is only responsible for the creation and renaming of Team? I believe Company must create Team in order to enforce the rules, and be responsible for renaming, but that is all.

My question is: is this normal? Is splitting a domain concept across Aggregate Boundaries a normal way to enforce invariants?

The only alternative I can see is to move the entire Team Aggregate into the Company Aggregate. But in this case, I'll be storing a reference to a non-aggregate within Report.

I'd imagine this is a common modelling problem, but Google is failing me!

Any help is much appreciated!

Answer 1

Team.Name must be unique per Company

Why ? Is that really a domain invariant or more of a technical rule so that you don't confuse 2 teams on the team admin UI ?

If the latter, you should probably let the Application service handle that rule by asking TeamRepository and returning an exception when the uniqueness is broken.

Merging the Company and Team aggregates could be an option, but it seems like a very small domain rule to me to cause such a transformation. Even more so if the 2 aggregates are already big and could cause contention and concurrency problems put together. And with Report (presumably an AR ?) referencing Team, you can already see that Team will likely be a central point in your application. It seems weird to encapsulate it in something else.

http://gojko.net/2010/06/11/udi-dahan-the-biggest-mistakes-teams-make-when-applying-ddd/

http://thinkbeforecoding.com/post/2009/10/28/Uniqueness-validation-in-CQRS-Architecture