Честно говоря, все эти репозитории основаны на мнениях.
Вот как Мартин Фаулер определяет это:
Система со сложной моделью домена часто получает преимущества от уровня, такого как предоставляемый Data Mapper (165), который изолирует объекты домена от деталей кода доступа к базе данных.В таких системах может быть целесообразно создать еще один уровень абстракции над уровнем отображения, где сосредоточен код построения запроса.Это становится более важным, когда существует большое количество классов доменов или много запросов.В частности, в этих случаях добавление этого слоя помогает минимизировать дублирование логики запросов.
Репозиторий является посредником между доменом и слоями отображения данных, действуя как коллекция объектов домена в памяти.Объекты клиента создают декларативные спецификации запросов и отправляют их в хранилище для удовлетворения.Объекты могут добавляться и удаляться из репозитория, как и из простой коллекции объектов, и код отображения, инкапсулированный репозиторием, будет выполнять соответствующие операции за кулисами.Концептуально репозиторий инкапсулирует набор объектов, сохраняемых в хранилище данных, и операции, выполняемые над ними, обеспечивая более объектно-ориентированное представление уровня персистентности.Хранилище также поддерживает цель достижения чистого разделения и односторонней зависимости между доменом и слоями отображения данных.
Как вы отметили в своем вопросе:
Но ячасто можно увидеть, что интерфейс репозитория содержит методы, инкапсулированные в сложные запросы, которые не связаны с интерфейсом коллекции.
По моему мнению , в контексте DDD репозитории должны работать так, как вы объясняете (интерфейс коллекции) в вашем вопросе.Отдых - это бизнес-логика, и она должна перейти либо к доменной модели, либо к услугам.
Теория остается теорией;пуристы строго следуют этому.Прежде всего, это бизнес-потребности.
Шаблоны хороши, и им нужно следовать.Они созданы экспертами на основе их многолетнего опыта.Не стесняйтесь использовать его, если под рукой та же проблема.
Шаблоны, подобные репозиторию, немного шире, чем шаблоны GoF.Это делает репозиторий немного основанным на мнении.Кроме того, репозитории широко используются и вне контекста DDD.Это еще более суммирует мнения.
Кажется, репозиторий - не лучшее место для этих методов.
Если вы так думаете и у вас есть лучшее место в вашем дизайнедля этих методов, идти вперед и переместить эти методы в это место.Если ваш дизайн говорит вам, что хранилище - лучшее место для этого метода, не стесняйтесь его использовать.
Где разместить эти запросы?
На ваше усмотрение.Сосредоточьтесь на проблеме, сосредоточиться на своем дизайне, сосредоточиться на потребностях вашего бизнеса.Не добавляйте ненужную сложность в свой код просто, чтобы правильно следовал шаблону.Какая польза от паттерна, если он создает новые проблемы, исправляя обещанный?