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 Accreditation and Badges.
Solution One
In a first design of the system we had modeled an Event aggregate (see Figure 1), where all business logic around Accreditation, Badges, and future business use cases would live.
Figure 1: Event aggregate
Solution Two
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 Accreditation and Badges. However, because they all refer to the same physical event, they only identifier we could come up with was the same eventId.
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.
Solution Three
Another solution would be the "natural" DDD approach where we would treat 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.
Question
The question in this case is which of the following solution seems the most efficient and DDD-like approach?
