> p.s. собственно, если в бд сокращать количество таблиц -> то мы не сможем контролировать достоверность id внешних ключей

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

На тему сокращения количества таблиц - я бы сокращал количество связей. Ну то есть для ACL который ты пытаешься реализовать тебе ж по сути не нужно знать "типы" таблиц. Ты всеравно не сможешь так FK организовать. А ACL в куче таблиц как-то неудобно...

> вопрос, как в doctrine в рамках symfony мне сделать класс для  того, чтобы он сам определял по переданным в него аргументам в какую таблицу записывать?

делаешь сервис, там эту логику прячешь.

годно) как показывает практика к этим выводам команда или определенные люди должны еще дойти

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

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

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

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

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

буквально 2-3 ревью и человек пишет уже как и остальные

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

самодуры это вообще рак в индустрии

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

я постоянно слышу истории про таких людей и сам сталкивался с этим несколько раз

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

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

А  действительно, нафига тебе контроллер из одной строчки? Он прросто лишний, сразу роут на хендлер направляй и ок.

Кто-то где-то когда-то услышал, что логики в контроллерах быть не должно. Поэтому всё что с приставкой *Controller теперь return $this->handler->handle($request)
Контроллер есть, а логики нет. Миссия выполнена

Нахера он тогда нужен вообще

Ты прото переместил свой контроллер в хендлер

Ух насыпал соли на рану😁

По сути просто добавил лишнюю прослойку

Ну так логики нет. Всмысле не только в контроллере )

Контроллер это ж хттп адаптер в приложение

Точки входа проще искать с наличием контроллеров

Поэтому да, bus->handle(command), и больше там ничего не надо

*в большинстве случаев

Http контроллер должен взять запрос, преобразовать его  в удобоваримый для твоего сервиса вид  и передать ему. А если ты сареквест передаёшь, то ты просто запихнул http контроллер внутрь сервиса. Ну илм припили ещё один, который выполняет функцию контроллера

Кидать всё в bus думаю смонительно, но да ладно. Проблема в том что ты в своё примере передаёшь command, то есть твой контроллер всё же занимается конвертацией реквеста в команду.
А обычно в хендлер объект реквеста as is передают

скорей всего речь идет об отделении бизнес логики от фреймворка. что б можно было сменить фреймворк, не меняя код логики. Только в этом случае неизменный реквест туда передавать не надо. Об этом рассказывал Роберт Мартин. Он предложил использовать Interactors или Use Cases.

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

а если внутри все тот же getUser и request.. то хз зачем