In DDD, creating smaller aggregates is encouraged where possible, but in a system we are designing we are running into an issue regarding the identity of aggregates.
The system evolves around phyisical events, like music festivals or sports events, and within these events there are separated bounded contexts representing some business use case. For example, there can be
In a first design of the system we had modeled an
Event aggregate (see Figure 1), where all business logic around
Badges, and future business use cases would live.
Figure 1: Event aggregate
However, this would result in a huge aggregate, so we decided it would be best to split these up into smaller aggregates (see Figure 2).
Events itself was no longer a concept because we had split these up into separate
Badges. However, because they all refer to the same physical event, they only identifier we could come up with was the same
Implementing this with event sourcing would also raise the issue that there are multiple event streams with the same identifier.
Figure 2: Split aggregates with shared identity.
Another solution would be the “natural” DDD approach where we would tread the different modules as Entities with their own identity (see Figure 3). This however, feels very unnatural and does not represent the actual domain logic. In the implementation we would therefor also need a lookup table of some sort to map the
eventId to the required
moduleId (see Figure 4).
Figure 3: Split aggregates with own identity.
Figure 4: Lookup table that maps the event to their modules.
The question in this case is which of the following solution seems the most efficient and DDD-like approach?