Могут ли в объектно-ориентированном дизайне иметь свои собственные репозитории?

Question

Я работаю на довольно стандартном веб-сайте электронной коммерции, где есть Продукты и Категории. Каждый продукт имеет связанную категорию, которая представляет собой простой объект пары имя-значение, используемый для категоризации продукта (например, элемент 1234 может иметь категорию «баллон»).

Я смоделировал продукт как корневой агрегат, который владеет и знает, как изменить его категорию, которая является объектом.

Однако я столкнулся с проблемой, когда пользователь должен иметь возможность искать категорию. Как я должен реализовать это в DDD? Я новичок в DDD, но я считаю, что только корневые агрегаты должны иметь свой собственный репозиторий. Так что у меня остается 2 варианта:

1. Добавить метод SearchCategory в ProductRepository
2. Реализация логики поиска как службы (т. Е. CategoryFinderService)

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

Может кто-нибудь сказать мне, как лучше всего это реализовать?

Answer 1

ИМХО, в вашей доменной модели категория не должна быть дочерней по отношению к агрегации продуктов.У продукта есть категория, но он не знает, как создавать или редактировать категорию.

Возьмем другой пример.Представьте себе класс ShoppingCart , это сводный корень и содержит список Items . ShoppingCart отвечает за добавление / редактирование / удаление элементов , в этом случае вам не понадобится репозиторий для класса Item .

Не уверен, кстати, я новичок в этом, как и вы.

Answer 2

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

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

Answer 3

Не пытайтесь реализовать все с вашей моделью домена. Модель предметной области является мощной для изменения состояния системы, но ненужным комплексом для запросов. Так что отделите их. Это называется разделением ответственности по командным запросам или CQRS. И нет, это не имеет ничего общего с Event Sourcing, хотя они прекрасно работают вместе.

Я реализую такие сценарии, чтобы у меня была логическая сторона домена с объектами и репозиториями домена (при необходимости), которые изменяют состояние, когда что-то происходит, т.е. размещается новый заказ или отправляется заказ. Но когда мне просто нужно показать что-то в пользовательском интерфейсе, например, список продуктов, отфильтрованных по категории, это простой запрос, который вообще не включает объекты домена. Он просто возвращает объекты передачи данных (DTO), которые не содержат никакой логики домена.