Имея совокупный корень как свойство? - PullRequest
Новая
       2

Имея совокупный корень как свойство?

2 голосов
/ 20 февраля 2012

Может ли совокупные корни иметь потомки, которые также являются совокупными корнями?Если да, ссылается ли он только на него, или у агрегатного корня, который содержит свойство другого агрегатного корня, есть методы, которые изменяют его с помощью этого метода?

Допустим, у вас есть класс с именем "Рабочий" и другой с именем"Компания".Оба являются совокупными корнями.Компания имеет собственность работника. Извините за плохой пример 

public class Company {
    private Worker worker;

    ...

    public Worker getWorker() {
        ...
    }
}


public class Worker {
    ...
}

или класс компании "скрывает" работника? 

public class Company {
    private Worker worker;

    ...

    public String getWorkerName() {
        ...
    }
}


public class Worker {
    ...
}

И работник говорит только с классом компаниипотому что это не является частью контекста компании?Почему так?Всегда ли доступны агрегатные корни внутри других агрегатных корней, как в моем первом примере?(Я бы так подумал, но у меня нет причин, почему)

1 Ответ

1 голос
/ 20 февраля 2012

Короче, нет.

Это довольно сложно объяснить кратко в SO-ответе, но вот несколько пунктов, которые могут помочь вам понять:

  • Совокупный корень является границей согласованности. По сути, все данные, которые необходимо поддерживать согласованными, принадлежат совокупному корню. Вы будете знать, что он правильно структурирован, когда обладает высокой связностью - большинство методов затрагивают множество частных свойств.
  • Все взаимодействие с агрегатным корнем или его дочерними элементами должно осуществляться с помощью открытых методов в агрегатном корне. В вашем примере, если работник принадлежит компании, то добавление / удаление работника или выполнение каких-либо операций с работником должно выполняться с помощью общедоступных методов в компании.
  • Вы можете иметь сущности ниже совокупных корней, но, по моему опыту, это часто является запахом дизайна. По моему опыту, чаще всего у вас есть объекты-ценности как дочерние элементы агрегатов.
  • Корреляция между агрегатными корнями осуществляется с помощью идентификатора, поэтому Компания может знать о GUID, называемом WorkerId, но он определенно не должен быть связан с классом Worker. (Это позволит вам легче выполнять рефакторинг.)
  • Вам нужна модель предметной области (и, следовательно, агрегированные корни), только если операция (т.е. метод) зависит от предыдущего состояния данных. Если нет изменений состояния, просто сделайте CRUD.
...