Domain Driven Design: Aggregate root problem

Question

Hi all,

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.

Answer 1

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:

• Garages and Organisations both own a RuleSet, which is made up of any number of rules; I don't think having Garages (etc) bound direcly to a Rule is what you actually mean / or want.
• I've subtyped the RuleSets as you might want to have different logic applied at that level.