CODEWITHSUNDEEP
c#nosqldomain-driven-design
user1450877
user1450877

Reputation: 421

how to handle two separate aggregate roots holding reference to same data?

In a domain model that models sports events how should this scenario be handled, especially in the context of using a no sql document database to hold the data.

The main entities in the system are Season, Tournament Group, Tournament, Tournament-Stage, Match, Player.

Season - A Season has a start date, end date, an ordered collection of Player and a collection of Tournament.

Tournament Group - A tournament group contains a collection of tournament, each tournament can only belong to one tournament group. I am unsure if this should actually be an entity.

Tournament - A Tournament has a start date, end date, an ordered collection of Player and an ordered collection of Tournament-Stage.

Tournament-Stage - A Tournament-Stage has an ordered collection of Match. Not sure if this should be an entity as its just a way to group matches with in a Tournament.

Match - A Match contains a collection of Player.

This is where it gets confusing for me be because I would say so far that the aggregate root is the Season but there will be I don't know where the Player fits into this model and I'm probably not dealing with tournament group properly either.

Statistics need to be generated to for a Season, Tournament Group and Player e.g. Who scored the most in a Season, Who scored the most in a Tournament Group and for a Player which Tournament, Season or Tournament Group he scored most in.

To get this data I would have thought that the Player entity would have to hold references to Tournament and Match but these references are also help by Season. Is this acceptable and what is the best strategy for updating the data in one aggregate root if it changes in another ?

Upvotes: 0

Views: 126

Answers (1)

Yves Reynhout
Yves Reynhout

Reputation: 2990

It's not an easy question to answer since most of what you describe is a glossary of your domain with hints of what the behavior is (but without an importance attached to that behavior). If you were to write down each scenario your model had to support (that you know of thus far) and then create, challenge & evolve that model by trying to implement each of those scenarios, you'd end up with something completely different from what is described above. Probably multiple models that each solve different aspects. Aggregates are clusters of behavior oriented around a set of entities and value objects, not entities as nouns you try to retrofit behavior into.

If I'm to give you any advice, separate the administration of seasons, tournaments, etc ... from actually recording what happens during the actual season, from reporting any types of statistics you might want to derive during or at the end of the season.

Upvotes: 1

Related Questions