Намекаешь что в истории с контроллерами из одной строки могло быть что-то, в чём стоило разобраться?)

нужно сразу выждать и ситуацию оценить)

возможно на проекте уже сотня таких контроллеров, и не хотят плодить зоопарк, при этом заменить сразу везде нет времени

То есть я смотря на это "легаси" должен продолжать писать так же?
Проще уволится, ибо уже через месяц мотивации продолжать что-то делать в этой жизни не будет

за месяц можно накопать проблем и посерьёзнее)

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

или с первых дней доебуешься до таких мелочей вместо того чтобы въехать в домен и процессы?

для этого испыталка и есть, она в две стороны идёт)

Проблемы были на всех уровнях, я написал про те которые лежат на поверхности и с которых как правило и начинается.

Если я знаю способ эффективнее/проще и понимаю что я делаю я тупо не стану писать как "все" если все пишут херню.

Предлагаешь начинать "доёбываться" не с малого, а сразу по большому?)

Бывает такое, что фреймворк бросают, например angularjs. если у вас логика отделена от контроллеров, то перейти на другой будет легче.

Также, логику, вынесенную в хендлеры, которые не зависят от реквеста, можно запускать и в CLI command, и в queue worker.

Еще в тестах это удобнее. Логику, отделенную от фреймворка можно протестировать сотней тест кейсов, которые выполнятся за 200мс. Если логика находится в контроллере, то 1 тест кейс может выполняться несколько секунд, каждый раз поднимая ядро фреймворка. Тестировать логику, а не фреймворк. Хотя логику + фреймворк тестировать тоже надо, но это функциональные тесты, они проверяют только критический путь.

Say the line как переводится?)

когда ты встречаешь чела который снимался в заезженной рекламе где говорит одну фразу, и доебуешь его "давай, скажи это!"

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

Ели в приложение есть следующие кейсы:
один  и тот же бизнес сценарий может быть запущен в результате
  - http запроса от АПИ
  - в результате http запроса в результате отправки формы(формат данных отличается от того что в АПИ)
  - есть несколько разных версий АПИ, которые отличаются по формату, но дергают одну  и ту же бизнес логику
  - в результате обработки сообщения из очереди
 - в результате soap запроса
 -  и т.д.
то выделять  бизнес логику в сервис (usecase, интерактор) - так или иначе придется.
Фактически в приложение появляются слои
 - слой обработки http /soap / grpc и т.д.
- слой в котором инкапсулированы бизнес сценарии
- слой в котором инкапсулировано знание о сущностях
ну или нарезка на слои может следовать какой либо другой логике.
От слоев есть практическая польза когда они имеют явно выраженные границы:
  -  т.е. верхний  слой знает о слое нижнем (но не знает о следующих слоях),
  - а нижележащий слой не знает ничего о верхних слоях (по аналогии - сетевой карте должно быть без разницы, отправляет она udp или tcp пакеты, и уж тем более без разницы кто шлет эти данные - браузер, или телеграм)
такая изоляция требует появления специальных контейнеров данных которые нужны для передачи информации между слоями- т.е. появляется Data Transfer Object - DTO. Если dto не вводить , а фигачить через все слои тупо один объект (например http request), то фактически это про протекание слоев.

Т.е. все эти слои они решают вполне конкретную задачу - сделать код устойчивым к изменениям:
 - пришел клиент дал много денег что бы склепали апи на каком то некрофильском бинарном протоколе -пожалйста -> слой бизнес логики не трогаем, делается отдельный контроллер в нем логика по тому как смапить данные из протокола на dto для сервиса, и как из dto ответа сервиса - создать ответ в формате протокола
- решили поменять реализацию бизнес сценария
   - ну например раньше в рамках бизнес сценария состояние сущностей хранилось в  бд, а потом пришли микросервисы - и вот реализации бизнес сценария поменялось - в нем теперь не с сущностями работа идет, а дергуются другие апи.
   - тогда можно не переписывать все контроллеры/консольные команды/обработчики сообщений , а поменять реализацию интерфейса класса в котором инкапсулирвоана логика бизнес сценария

Другое дело что решаемые задачи характерны далеко не для всех приложений. Контроллер в одну строчку - имхо, это следствие не понимания какая именно задача решалась при вынесение бизнес логики в отельный сервис (отсюда и кривая реализация в виде пробрасывания http request внутрь сервиса)

Я вот накину. Чисто для себя (от других в рамках работы я этого не ожидаю) я стараюсь почаще вспоминать цитату:
"«Поучать человека — значит обвинять его в слабоумии. Обвиняя человека в слабоумии, добиться позитивного результата невозможно. Единственный способ чем-то его поправить — это явить ему некий пример, который научит его без всяких слов» - автор давно умерший самурай"
Ну вот пришел я на новый проект, сказал что линтера у вас нет, контроллеры в одну строчку, ну и потряс синей книгой Эванса гневно крича про DDD - ну какая реакция должна быть у коллектива? Ну по честному какая?
В проекте где команда не более 8 человек, ну вот вся эта тема с кодинг стайлом, контроллерами в одну строчку - это все очевидные проблемы, которые бросаются в глаза и про которые говорить проще потому что они очевидны.
 Ну какой профит будет по времени от решения этих проблем ? Ну т.е. вот разработчик в неделю делает n тасков за x времени, вот прикрутят линтер, перестанут контроллеры в одну строчку делать - будет 2*n тасков за x ? Ну фиг знает- я примеров подобного не видел - если у вас было такое - расскажите. Ну может не 2*n тасков за x, а 1.5 за x?
А что бы понять глубинные проблемы, и исправить их - нужно время , вот по моему опыту это 6-9 месяцев пребывания на проекте, пока человек не начинает понимать его устройство на таком уровне, что бы действительно видеть суть проблем.

да, так и есть. Хорошо, если четко понятно, когда проект это однодневный прототип, а когда большое приложение

ну вот как бы да - есть системность мышления - возможность определить
а) какую задачу я решаю и почему
б) выбрать наиболее короткий путь к решению задачи
в) сформулировать критерии оценки что бы понять что задача действительно решена

если этого нет, то начинается:
"Наука — лучший способ удовлетворения личного любопытства за государственный счёт"
только не наука а изучение фреймворка/технологии и не за государственный, а за счет работодателя .

подскажите пожалуйста, пытаюсь через ORM отфильтровать данные со связанной таблицей (left join) но почему то игнорирует этот фильтр

$qb->leftJoin('a.tags', 'b');
$qb->andWhere('b.tag = :tags')->setParameter('tags', $tag );

связь вообще организованна как "многие ко многим"

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