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!