В чем разница между репозиторием и поисковиком в Seedstack?

Несколько сложно объяснить это в нескольких строках, потому что решение о моделировании исходит из глубокого понимания DDD, CQ(R)S, моделей быстрого чтения, согласованности в конечном итоге и т. д.

• Искатели

Как говорится в руководстве: «Запросите слой сохранения или любой источник данных, чтобы получить объекты, специфичные для интерфейса приложения». Ключевое слово здесь — Интерфейс. В случае графического пользовательского интерфейса средства поиска используются для извлечения конкретного представления, чтобы представить его в настольной форме или на веб-странице. В приложении, отличном от CRUD, пользовательский интерфейс должен быть на основе задач, поэтому:

1. Ваши представления не соответствуют вашим Сущностям и Агрегатам.
2. Ваши Сущности и Агрегаты не содержат (не должны) полные списки данных выбора, т.е.: Штаты и Города (классические поля со списком каскадных зависимостей)
3. Ваши агрегаты и сущности не содержат (не должны) полный список ссылочных сущностей (класс Customer с огромным списком заказов со всеми данными заказа, размещенными внутри, является неправильным совокупным моделированием DDD), но где-то в вашем приложении вы должны показать полный список заказов.
4. Ваши Представления и Агрегаты могут быть получены из разных источников данных (обычно для производительности запросов и/или согласованности событий). то есть модели чтения NoSql, ненормализованная реляционная база данных или предварительно вычисленные представления (вместо таблиц, представляющих ваши объекты) в реляционной базе данных вашего домена.

Таким образом, у вас есть несоответствие импеданса между пользовательским интерфейсом и агрегатами/сущностями. Лучший способ решить эту проблему — явно создать способ перехода от сохранения к просмотру. Искатели вступают в игру.

• Репозитории

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