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

В Service классах

ну вот этого и не хочется делать, тогда они получаются очень пухлыми

В scopes модели, в сервисном слое.
Комбинировать.

Пухлый service === пухлый Repository
в чема разница

сервис + репозиторий, я не предлагал заменить сервисы репозиториями)

scope ну их нафиг, модели лучше оставить пустыми, я даже стараю Observer использовать в крайнем случае

Тогда зачем вам Eloquent если можно обойтись обычным Builder?

чтоб изменения одной и той же модели не расползались по проекту

Builder + Repository + Entity

да, я тоже думаю что в модели нужны только релейшены максимум, Eloquent нужен чтобы в репозитории или в сервисе написать выборки данных или запросы на их изменения, используя релейшены, а не Builder, потому что в случае с Билдером при любом изменении поля тебе придется переписывать все запросы

=== Doctrine

😃

Тождественно точно не равно )

равно, посмотри на досуге как работает Doctrine, там тоже своего родп Builder есть и Репо и Entity

и по всему проекту гуляет зависимость от EntityManager

Я с ней работаю 4 года)

Но спорить не буду, очень много работал с множеством лидов, которые любили пихать работу с базой в репозитории, а как доходили до необходимости смены хранилища, сразу попадали на боль ибо подменить реализацию по интерфейсу как разукрашивал лид изначально не выходило или придерживались SlimModel(А-ля толстые модели плохо, нужны репозитории, нужны Query объекты в проекте с 10 модельками и всего 30 RESTful-like методами), тем самым раздувая какой-то другой слой и создавая свои прикольные абстракции для работы с БД, которые уже существовали в самом фреймворке…
Но Eloquent в свою очередь является красивой AR, быть “тонким” AR по факту не положено, а используемый MVC, как бы на это тоже намекает (Model - данные и правила, которые используются для работы с данными, которые представляют концепцию управления приложением). Не говорю, что все необходимо писать в моделях, однако это уже вопрос проектирования системы в целом.

При этом держать модели тонкими, боясь использовать наблюдатели или заготовки ради “эстетики в сущности”(которая в таком случае в принципе больше походит на Entity, вроде и мутабельна, но еще и сама с базой работает), но при этом раздувать какой-то из других слоев (Сервисный, Репозитории, *Query объекты,  *Search объекты) тоже не очень хорошо.

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

толстые модели я не знаю откуда ты такое взял, такое в гайде по юии написано)

впринципе файл не должен быть больше 200 строк, если в модель напихать всю работу с данными, это будет адский треш, модели вырастут до 2-3к строк, уже видел такие проекты... и всю боль разрабов