Проектирование на основе домена: совокупная проблема с корнем - PullRequest
Новая
       32

Проектирование на основе домена: совокупная проблема с корнем

2 голосов
/ 18 октября 2010

В настоящее время я не знаю, как определить совокупный корень.

У меня есть следующие классы. 

- Garage
- Organisation
- RuleSet
- Rule
- OrganisationRule
- GarageRule

A Garage может иметь много Organisations.

A RuleSet - это объект, на который ссылаются Rules.

Существуют Rules, которые непосредственно связаны с RuleSet.

Тогда есть OrganisationRules, которые связаны с RuleSet и Organisation.

Наконец, есть GarageRules, которые связаны с RuleSet и Garage.

ЦелымКонцепция набора правил и его правил заключается в том, что пользователь может добавлять правила в набор правил на уровне набора правил.Затем эти правила могут быть перезаписаны правилами, определенными на уровне организации.Опять же, для гаражей можно добавить более конкретные правила.

Итак, позже клиент хочет получить правила для гаража, он сначала проверит правила, которые непосредственно связаны с гаражом, а затем проверитдля правил на уровне организации, а затем на уровне набора правил.

Моя задача сейчас состоит в том, чтобы идентифицировать совокупные корни.Кроме того, если, например, RuleSet является совокупным корнем всех правил, я не знаю, как выполнять эффективные запросы, чтобы получить правило для конкретного гаража (их около 60000 гаражей).

Так, например: 

public class RuleSet
{
    public ICollection<Rule> MetaRules { get; set; }

    public ICollection<OrganisationRule> OrganisationRules { get; set; }

    public ICollection<GarageRule> GarageRules { get; set; } 
}

Или я должен сделать каждый объект правила своим собственным агрегированным корнем?Так что тогда я могу делать запросы, такие как garageRuleRepository.GetRulesByRuleSetAndGarage(RuleSet ruleSet, Garage garage).В противном случае я получу очень большие коллекции в моем совокупном корне, которые я не смогу правильно запросить.

1 Ответ

4 голосов
/ 19 октября 2010

Я разработал вашу модель, чтобы лучше ее понять - надеюсь, я понял все правильно.

Моя проблема сейчас заключается в определении Совокупные корни

Я бы подумал, что дочерние части совокупности знали, кто их родители; и учитывая, что (если я вас правильно понимаю) правило не может существовать без родительского набора правил, то вы наверняка сможете отобразить их обратно; То же самое относится ко всем остальным классам.

Или я должен сделать каждую сущность правила своей собственный сводный корень?

Нет - не путайте проблемы реализации с моделью.

Так что тогда я могу делать эффективные запросы такой как garageRuleRepository.GetRulesByRuleSetAndGarage (набор правил RuleSet, гаражный гараж).

Хммм - возможно. Если мы знаем RuleSet или RuleSet, мы должны знать, к какому гаражу он в конечном итоге принадлежит, поэтому вам не нужно передавать RuleSet.

В противном случае я в конечном итоге очень большие коллекции в моей совокупности root, который я не могу правильно запросить.

С одной стороны, вы можете загрузить полный граф объектов для Garage и поместить его в память, или вы можете загрузить только часть графика и использовать реализацию на основе LazyLoad для получения информации, если и когда это необходимо.

Это зависит от архитектуры ваших приложений; если у вас есть память для хранения полного графика и получение данных было дорогостоящей задачей (т. е. вы хотите делать это как можно меньше), то, возможно, первый способ лучше; если памяти мало, но получение информации не является бременем, то, возможно, последнее.

Ваша модель основана на вашем оригинальном вопросе: alt text

Моя предложенная модель:

alt text

  • Гаражам и организациям принадлежит набор правил, который состоит из любого числа правил; Я не думаю, что привязка гаражей (и т. Д.) Непосредственно к правилу - это то, что вы на самом деле имеете в виду / или хотите.
  • Я подтипировал наборы правил, так как вы можете захотеть применить другую логику на этом уровне.
...