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.

enter image description here

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.

enter image description here

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).

enter image description here

Figure 3: Split aggregates with own identity.

enter image description here

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?

• Laiv: It might interest. Just in case you didn't read it yet. Hope it helps.
• Filip Milovanović: Just for clarification (may help with the answers): (1) "within these events there are separated bounded contexts" - as the term "bounded context" is often used in the wrong way, can you say a few words on what do you mean by this? (2) You said "this would result in a huge aggregate" - in what sense, and what are your (practical) concerns? It's not clear from your question or the pictures. (3) Give us a bit more info about the domain - what are the elements of your model? E.g. What are these events (yellow boxes) within the Event aggregate, why they share the same ID, how are they represented?

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.