Да и банально ну поработай ты в одном интерфейсе с инмемори бд, файловой системой и реляционкой

Что у них общего кроме четырех операций сверху, и то не всегда

Ведь когда мне вбивали понятие репозитория, мне говорили меняешь драйвер и ок, рили?)

Удачи)

Репозитории бессмысленны в контексте ларовского элока. Начинать нужно с того, чтобы писать запросы в контроллере, если они начинают повторяться и есть потребность вынести в одно место - возможно хромает логика, если нужна модульность типа динамичных фильтров - уже тогда стоит думать о том, что делать. Обычно те, кто используют подобные недорепозитории банально используют их "чтобы было" или "ну зашквар в контроллере же", при этом у них 5 контроллеров на всё приложение. Элок это уже репозиторий с кучей драйверов, а если нужно больше - уже зависит от задач, может тогда вообще эластик нужен, а не реляционка.

А по мне так это сервис)

Так в сервис же

Сервис сервису рознь. Если это просто класс с кучей методов на каждый запрос - это опять же такой себе вариант, просто переместить код - это как под ковер замести)

Контроллер и так отвечает за вызов мидлвайрей, политик, валидации, моделей, сервисов, формирует ответ, куда ему ещё)

Тут понятно, что хелперный класс со статикой не сервис

Если в твоем приложении их 5 и запросы не сложные - в контроллере им самое место, имхо. Я не о том, что всегда нужно их там хранить, а о том, чтобы не простреливать себе ногу на этапе, когда тебе это не нужно

Так те действия что я описал там и должны быть)

Все забывают почему то, что все эти сервисы выполняют свой функционал

И там за тенью может быть ого-го как скрыто

Не сервисы

А интерфейсы

Контроллер просто дёргает по очереди и ответ возвращает

В зависимости от экзепшена или успеха

Когда ого-го что скрыто - это уже не относится к тому, о чем я)

Так даже мой пример посмотри