How to split Aggregate Root that have equal identity?

Question

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?

Answer 1

It's normal to have multiple "aggregates" that are interested in the same correlation identifier.

Mauro Servienti has a talk that discusses how a "monolithic" aggregate might break down into smaller, more focused elements.

If you were doing this with event sourcing, the correlation-identifier that binds the different aggregates together would probably become part of the stream identifier

/accreditation/0a4f2945-8480-426a-86b3-5f3abac17a67
/badges/0a4f2945-8480-426a-86b3-5f3abac17a67

More generally, you would have a lookup function somewhere that takes the correlation identifier as an argument, and returns the other identifiers that you need, which allows you to start working around the unusual cases that may arise.

badgeId = badges(0a4f2945-8480-426a-86b3-5f3abac17a67)

Finding a stream given some amount of information is fundamentally a plumbing problem, and you'll face the usual complexity vs investment trade offs there.