Entity lives in multiple aggregates in the same form

Question

Context: Currently designing a product with a DDD mindset. Currently in a monolithic approach. However I'm refactoring a few things so I can change to a more loosely coupled monolith.

We have an entity called "Risk" (which is an abstract class with N subtypes). Currently have two aggregate roots who have a list of risks: Contract and Damage. This is demanded by the business logic, as when you create a damage from a specific risk in a contract, you need to take an exact copy of it at that given moment in time and add it to the damage.

However there's a new business rule that allows Customers (yet another aggregate root) to have a list of risks as well, without having any contract or damage (=> A prospect customer). The risk entity that would live under the Customer aggregate is an exact copy of the risks entity under contract & damage. The business itself is required to have the same data properties & behavior to the risk.

I'm not really a fan of sharing entities all over different aggregate roots, especially with the mindset of splitting it up to a more loosely coupled monolith. Plus the fact that the risk entity itself is an abstract with multiple subtypes.

Would a better approach be to make Risk an aggregate root as well and keep a reference ID to either a Customer, Contract or Damage?

Any advice is welcome!

Answer 1

Without knowing exactly what you are building, it seems you've come to the natural conclusion that makes the most sense:

Would a better approach be to make Risk an aggregate root as well and keep a reference ID to either a Customer, Contract or Damage?

Based on what you shared, it makes the most sense.

There are several cases where aggregates are associated with other aggregates, but the business logic surrounding it really suggests that it is it's own aggregate root.

For example. I have a system where we maintain metadata on a corpus of information, and users can make different types of requests against that corpus. In this example, we'll call the corpus a "Collection", and the request types being "Information" or "Services". All of the requests are children of the "Collection", but there are whole workflows around fulfilling those requests.

So in this almost contrived example, we have:

• Collection (1..n)
  • Request: Information (1..1)
  • Request: Service (1..1)

We found it worked better to have "Requests" and "Collections" be peers, and the "Request" was associated with a "Collection".

The requests have their own approval and fulfillment workflows independent of the collection's approval workflow. We've gone to a full microservices architecture already, and this approach of promoting an aggregate element to be it's own root just made the whole design easier to comprehend.

Some of the clues that suggest something is a candidate to be promoted to it's own aggregate root and simply referenced by it's logical parent include:

• The customer talks about that thing independently of the parent. (in your case risks)
• The same aggregate type can be associated with multiple types of parents. (Contract, Damage, Customers)
• There are independent workflows/business logic surrounding the child and the parent

Those are just a few reasons, and there could be more rational reasons to promote something to be it's own aggregate root. By doing this, you essentially decouple the concepts--but maintain the referential link you need.

Answer 2

Here are a few recommendations depending on the actual domain:

• Whether Risk should be an aggregate by itself, or part of the Customer, Contract, or Damage depends on whether it is an invariant in those aggregates. If the others cannot exist without a Risk, it makes sense to make Risk an entity of those aggregates.

• If Risk has its own lifecycle, entities, business logic and can change over time, it probably should be modeled as an Aggregate. In which case, it cannot be part of transactions of the other aggregates. The Risk aggregate must be created first and then referenced by others by its ID in their own transactions.

• If you want a snapshot of the Risk to be taken when other aggregates are created, you will have to create an entity under each of Customer, Contract, and Damage. The entity should be populated with data from the master Risk record during aggregate creation.

• There is a middle path between creating an independent copy of Risk across aggregates vs. referring to a Risk by its ID. You can create denormalized Risk records as entities under other aggregates (or even across different bounded contexts), which are updated by listening to Domain Events published by the Risk aggregate during its lifecycle.