Reputation: 7359
currently I dont know how to identify an aggregate root.
I've got the following classes.
- Garage
- Organisation
- RuleSet
- Rule
- OrganisationRule
- GarageRule
A Garage
can have many Organisations
.
A RuleSet
is an entity where Rules
are referenced to.
There are Rules
that are directly associated with a RuleSet
.
Then there are OrganisationRules
that are associated with a RuleSet
and a Organisation
.
Finally there are GarageRules
that are associated with a RuleSet
and a Garage
.
The whole concept behind a rule set and its rules is, that a user can add rules to rule set on rule set level. Then these rules can be overwritten by rules defined on organisation level. Again, more specific rules can that be added for garages.
So later, a client wants to get the rules for a garage, it will first check the rules that are directly associated with a garage, then it will check for rules on organisation level, and then on rule set level.
My problem now is to identify the aggregate roots. Plus, if for example RuleSet is the aggregate root of all rules, I dont know how to do performant queries to get a rule for a specific garage (there are about 60000 garages).
So e.g.:
public class RuleSet
{
public ICollection<Rule> MetaRules { get; set; }
public ICollection<OrganisationRule> OrganisationRules { get; set; }
public ICollection<GarageRule> GarageRules { get; set; }
}
Or should I make each rule entity its own aggregate root? So then I can do performant queries such as garageRuleRepository.GetRulesByRuleSetAndGarage(RuleSet ruleSet, Garage garage)
. Otherwise I will end up which very large collections within my aggregate root that I cannot query correctly.
Upvotes: 2
Views: 597
Reputation: 10205
I've drawn up your model so I could better understand it - hopefully I got it right.
My problem now is to identify the aggregate roots
I'd have thought that the child parts of the aggregate knew who their parent was; and considering that (if I understand you correctly) a Rule can't exist without a parent RuleSet the surely you can map them back; the same goes for all other classes.
Or should I make each rule entity its own aggregate root?
No - don't confuse implementation challenges with the model.
So then I can do performant queries such as garageRuleRepository.GetRulesByRuleSetAndGarage(RuleSet ruleSet, Garage garage).
Hmmm - maybe. If we know a Rule or RuleSet we should know which Garage it ultimately belongs to, so you shouldn't need to pass the RuleSet in.
Otherwise I will end up which very large collections within my aggregate root that I cannot query correctly.
On the one hand you can load up a the full object graph for a Garage and place it in memory, or, you can load only part of the graph and use a LazyLoad based implementation to get information if and when it's needed.
This depends on your applications architecture; if you have the memory to store a full graph and getting data was an expensive task (i.e - you only want t do it as little as possible) then maybe the former way is better; if memory is scarce but getting information isn't a burden then perhaps the latter.
Your model based on your original question:
My Suggesed model:
Upvotes: 4