modular-monolith-with-ddd | Full Modular Monolith application with Domain-Driven Design | Architecture library

How does one determine taking in to account my example above regarding games which is the correct way to models these aggregates and entities? What determines if entities should exist as child entities or as a separate aggregate root?

The existence of a domain constraints connecting information.

If all we needed was to capture a bunch of information provided to us, we wouldn't need a domain model; a database is more than adequate for data capture.

We introduce the domain model because either (a) we need to ensure that new information is compatible with information that we have already captured and/or (b) there are derived values that we want to compute locally (ex: because computing them locally reduces the error rate).

Rule: If we have a constraint that must always hold, and that constraint spans multiple pieces of information, then that information must all be contained within a single "aggregate".

The justification for the rule: information subject to a constraint like this must be changed atomically. In other words, we want all of this information to be part of a single unit for the purpose of data changes. Therefore, the domain entities that manage this information must all be part of the same "aggregate".

In the cargo shipping example taken from the blue book (Evans, 2003), we have a constraint on the misdirected property of a shipment: it must be true if the most recently recorded handling event for a container is inconsistent with the most recently assigned itinerary. It follows that these three pieces of information must be stored atomically (otherwise we risk inconsistencies in our stored data), and therefore that the domain entities that manage this information must all be part of the same aggregate.

I tend to imagine a graph - the data are nodes, and each constraint implies edges connecting the data subject to that constraint. Our rule then becomes "every graph must be contained entirely within a single aggregate".

A single aggregate can contain more than one of these graphs, but in doing that you are also introducing contention that is not inherent to the domain -- this is one of the forms of "accidental complexity".