есть старый добрый interface segregation principle - вот его мало кто юзает увы

самый простой способ форсить такую херню и заставлять людей думать - ввести тупых ограничений вроде "максимум 3 публичных метода у любого интерфейса или класса если он без интерфейса"

а если сделать репозиторий с выборкой по критерию (вроде так паттерн называется) (
function get(Criteria criteria) {...}
)

то такое допустимо?

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

ну то есть у тебя когда такая штука выходит - скорее всего ты что-то не то делаешь

(а может то и для твоего кейса норм, потому скорее всего а не наверняка)

но я обычно такую херню воспринимают как:

- попытки на уровень персистанса загнать авторизацию - аля get(ByIdAndTenant(entityId, tenantId))
- реюз структур данных для БЛ и UI - причем рано или поздно UI перевесит и ты будешь модель строить удобной только для этого.

Очень легко с такими подходами связанность на уровень базы переносить. Но справедливости ради проблемы прям с таким появляются только на тех масштабах где появляется желание чуть базу разделить. Думаю есть много ситуаций где боли от этого не почувствуешь.

ну то есть... у меня например в голове это выглядит так - если ты хочешь вернуть бизнес объект и у тебя там не тупо get(id) - то вопрос как так выходит, почему? почему мы не знаем с чем хотим работать? А если мы хотим вернуть DTO - а как этот дто попал в коллекцию? откуда наш репозиторий узнал про другие данные которые мы никогда в него не клали? Как так вышло что у нас крайне неявный датафлоу в системе и что нам так часто это dto надо рядом с другими методами для БЛ

ООП это все таки про флоу данных между объектами а не про классы

контрольный вопрос: а если мы делаем маленькие агрегаты (как в той статье которую выше кидали, типа спринты и таски), агрегат таска имеет айди SprintId на родительский агрегат спринта. теперь нам нужно получить все таски для спринта, например чтобы изменить их статус. мы можем поставить в репо в таком случае метод "getForSprint(sprintId)"?

можем, но я бы сделал отдельный сервис где все в sql закатал бы. потому что этот метод нужен только для UI и только в одном месте.

мы то можем сделать все что душе угодно, вопрос зачем

сегодня ты хочешь просто вывести таски, завтра хочешь еще инфу а кто делает (не просто айдишник) + детали спринта (не только айдишник). После завтра захочешь еще группировать их по свимлайнам каким. Причина для изменений у этого всего будет своя. Так зачем нам держать эту операцию вместе с другими. Шоб имя таблички реюзать (я серьезно такой аргумент у людей встречал)?

через месяц у тебя инфа кто делает переехала из твоей базы во внешнюю систему. На таски это никакого эффекта не оказывает (там была айдишка там осталась айдишка)

если батч-процессинг нужен в спринте - можно вытащить пачку идентификаторов тасков для спринта (при помощи SQL) и проводить все транзакции в цикле
Или у тебя будет возможность снять галочки у каких-то тасков перед действием и идентификаторы будут прилетать с фронта (то есть всё равно ты будешь получать их при помощи SQL без всяких репозиториев)

батч процессинг отдельная история - тут можно даже логику продублировать немного что бы повысить пропускную способность если того задача требует. Если речь идет о "закрыть 10 тикетов одним махом" или "переместить все незавершенные таски в след спринт или бэклог" - то да, цикл по айдишкам которые мы достали через sql и для каждой вызвать сервис-юзкейса или там еще как

"проводить все транзакции в цикле"

какие транзакции здесь имеются ввиду? в моем понимании мы вытягиваем 10 тасков в виде уже агрегатов, проходимся по ним, вызываем что то типа task.markCompletedWithComplexBusinessLogic(), и потом всех сохраняем назад?

можно сохранять по одному

а то потом 9 тасок из 10-ти все хорошо а 10-ая все портит и хз как быть - откатывать все или только один этот

ну либо так