As I'm drawing my project's classes diagram, I'm wondering...
Customer's relationship with
Order for example.
It seems pretty natural and logic to aggregate
Orders to the
User... So should I? Because while I don't see concrete pros doing this (maybe you'd find some?), I see cons:
Customer's instantiation, we have to inject the
Orderinstances while we don't necessary need them...
Customer's instantiation is slower than in the case of a simple relation because we have to query his orders everytime, even when we don't need them...
So in this example is it good or bad to aggregate orders to customers?
We can lazy load aggregates/composites which eliminate the cons I've have listed, alright. Still, it forces us to lazy load instead of inject the orders as dependency... This might be a cons by itself?
I could use directly the order repository to get orders from
id when I need and store the orders in a simple variable anywhere else in my code, not in the
Customer's property. So I guess there wouldn't be aggregation anymore...
So I still wonder if there is a more pertinent reason to implement aggregation than just "it's what we should do"?
Sidenote: I have seen other related questions but their answers are just theoric and generic. It doesn't help me in anyway to define in this kind of case which relation type should I use.