I am building an app that revolves around projects and clients. So I decided to create project and client as seperate entities. They each have their repository in the infrastructure layer.
Clients can add client data such as address, company name, status. These are stored in various different tables and hold a client Id as a reference. But they can essentially be seen as an extension of the user profile.
I somehow need to collect these data sets to display them in frontend screens.
First, I was confused wheter the client is an entity, and it's data sets are "something else". But reading about aggregates, I feel that this might be the way to go.
Since I am not very familiar with the concept of aggregates, and most infos I find on Google tend to be more philosophical than pragmatic, I was wondering:
Should the client entity be an aggregate root? If so, would it be assembled in the repository (infrastructure layer) from the various sources using entities for each data set? Then something like "client address" would be an entity of it's own. Since I have 20 to 30 different data sets for each client, I would need an according amount of entities. Does that make any sense?
The alternative I have been using up to this point was some kind of a service/helper function that queries the data sets using their Id's and returns their value for displaying in templates. But then, this data is neither an entity, nor is it associated with the client entity in any way, which feels wrong.
