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

Question

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

Answer 1

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

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

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

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