Если репозитории предназначены для совокупных корней, где должна идти логика доступа к данным для других объектов?

У меня есть несколько объектов, представляющих веб-приложение. В настоящее время у меня есть объект кластера для представления конкретного развертывания приложения. Внутри кластерного объекта у меня есть следующие объекты: Сервер, Клиент, Пользователь. Ни один из этих объектов не может существовать, не являясь частью кластера, поэтому я создал ClusterRepository для извлечения кластеров из базы данных. Теперь из кластера мне нужно получить список клиентов, предположительно, используя метод в объекте Cluster, например GetCustomers(). Теперь, моя первоначальная мысль заключалась в том, чтобы затем разгрузить работу этой операции в CustomerRepository, но поскольку репозитории предназначены только для совокупных корней, где должна идти логика доступа к данным? Это относится к классу обслуживания?

Ответы

Ответ 1

В сущности, корневой агрегат представляет собой любой объект, который может потребоваться извлечь как корень графа объекта. Просто потому, что конкретный объект является агрегированным корнем и имеет репозиторий, не означает, что другой объект, который является одним из его свойств, также не может быть агрегированным корнем - с ним собственный репозиторий.

Хорошим примером является система выставления счетов клиентов. Клиент, безусловно, будет совокупным корнем и будет содержать коллекцию счетов-фактур... Но для другой прикладной функции сам счет-фактура может быть агрегатным корнем с составными объектами LineItem в этом графе объектов.

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

ПРИМЕЧАНИЕ. См. также комментарии к комментариям. Хотя корневые объекты могут (и часто будут) ссылаться на другие корневые сущности, они недовольны (и это может быть слишком мягким поворотом фразы), чтобы позволить репозиторию для любого корневого объекта содержать функции, которые управляют (создают, обновляются, или удаляет) любой корневой объект в своем графе объектов, на который он ссылается. Любые такие референтные корневые объекты должны иметь свои собственные отдельные репозитории, а функции управления ими (создавать, обновлять и/или удалять операции) должны находиться в их репозитории, так что он находится только в одном месте.