Let's assume we have three aggregates:
Both Evaluation and Contract are referencing Employee (using an AggregateReference or the ID itself).
The problem is that both Evaluation and Contract very regularly need specific properties of the Employee for their business-concerns for example the name.
That would mean, that in most cases when loading Evaluations or Contracts i would also need to load the referenced Employee (at least parts of it).
This is very costly, especially when iterating over collections of Evaluations and Contracts.
Another possibility would be to design "EvaluationEmployee" and "ContractEmployee" as sub-entities under their respective aggregate-root. This would solve the problem, because they are now part of the aggregate and spring-data-jdbc would load them together with the aggregate-root.
But now we have another problem: Employees don't have back references to Evaluation and Contract (actually it's the other way round). And there are a few indicators for Employee rather being an aggregate than an Entity: for example Employees are never deleted, when i delete Evaluations or Contracts.
Is there better way to model this?
I solved my problem by creating two new Entities: "EvaluationEmployee" and "ContractEmployee". Because Spring Data Jdbc needs back-references to work properly, i created a View for each of those Entities with an added back-reference to Evaluation and Contract respectively. This works because i don't need to write the Employees (i only read them).