Интересно, почему репозитории всегда описываются как используемые специально для агрегатов. Разве не мотивировано использовать его для всех организаций?
Потому что агрегаты - это границы согласованности, представленные на уровне приложения.
То есть, да, репозитории отвечают за получение снимка состояния из хранилища данных и построение из него графа сущностей и значений, составляющих агрегат.
API репозитория предоставляет только совокупный корень, потому что он определяет границу согласованности. Вместо того, чтобы позволить приложению достичь произвольного места на графике и внести изменения, мы заставляем приложение взаимодействовать исключительно с корневым объектом. Имея это ограничение, нам нужно только посмотреть в одном месте, чтобы убедиться, что все изменения удовлетворяют бизнес-инварианту.
Таким образом, нет необходимости разрабатывать репозиторий для каждого типа сущности в вашей модели, потому что приложению не разрешено напрямую взаимодействовать с моделью на этой мелкой зернистости.
Другими словами, сущности в агрегате являются частными структурами данных. Мы не позволяем клиентскому коду напрямую манипулировать объектами по той же причине, по которой мы не реализуем списки, которые позволяют клиентам выходить за пределы API и напрямую манипулировать указателями.
В cqrs вы делаете см. «репозитории», которые используются не только для агрегатов, но и для других целей - репозитории также можно использовать для поиска кэшированных представлений о состоянии модели. Хитрость в том, что представления не поддерживают модификацию. В подходе, описанном Эвансом, каждая сущность имеет одно-единственное представление, которое выполняет все ее роли. В CQRS объект и объект могут иметь разные представления в каждой роли, но обычно только одна роль, которая поддерживает изменение объекта.
person
VoiceOfUnreason
schedule
27.09.2017
