а что с Data не так? сук... как по мне это лучше чем дто, хотябы отражает то, что объект с данными

Имхо перебор с кол-вом слоев, ну да ладно) А кто дтошку потом в респонс превращает? Какой то единый ViewEventListener с сериализатором? Или на каждую response дто еще респонсер ?

ну у меня несколько листнеров для этого)

1) враппер данных в dto v1 {} -> {data: {}, code: 0} 2) детектор контент тайпа с резолвом фектори: accept: application/json -> json 3) прокидывание всяких доп. данных в респонз 4) + тоже самое для исключений со всякими преобразованиями

Просто у тебя слой который является http слоем (контроллер), по факту с http не работает ни на входе, ни на выходе. Получается это некий слой прокладка дополнительная.

ну да, просто у меня контроллер является контроллером

решает удобство и понятность как фигачить апишки)

ага

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

не, контроллером я дто/модель отдаю)

Слушайте, а вот листенеры это конечно удобно. Но хорошо ли? Как избежать того, что когда проект вырастит не ходить и не парится мол "вот я обновлю щас эту сущность, это только триггернёт обновление в бд или ещё какой-нибудь листенер какую-нибудь работу наделает?"

Ну вот где эта граница. Где я пишу листенер и понимаю что он будет помогать а не выстреливать в ногу?

Слушайте, а вот листенеры это конечно удобно. Но хорошо ли? Как избежать того, что когда проект вырастит не ходить и не парится мол "вот я обновлю щас эту сущность, это только триггернёт обновление в бд или ещё какой-нибудь листенер какую-нибудь работу наделает?"

Слушайте, а вот листенеры это конечно удобно. Но хорошо ли? Как избежать того, что когда проект вырастит не ходить и не парится мол "вот я обновлю щас эту сущность, это только триггернёт обновление в бд или ещё какой-нибудь листенер какую-нибудь работу наделает?"

Для приведения к типам можно рефлексией получить карту свойств Дто и применить ее к входящим данным пред десериализацией

В симфе проблема в том, что события и хуки/интеншены одно и тоже

Хз когда там наконец отделят кернел от хттп кернела, всё жду

ой да, особенно когда пишешь свой бандл, а там ради 5 строчек кода приходится http кернел тянуть, хотя сервис вообще не про http

Не знаю что за коллбеки но просто когда читаешь иногда логику: A -> B -> C а по факту: A -> listener -> listener -> B -> listener -> C -> listener -> listener

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

ну банальный пример. Я смотрю есть роут регистрации пользака в живом журнале. Внутри него вызывается юзкейс в котором идёт описание логики. 1) размапь контекст на пользака 2) создай для него борд и на этот борд помести первую запись "я зарегистрировался!" 3) сохрани это всё дело Вроде всё просто, больше никаких действий нет, но как оказалось под ковром есть листенер который слушает персист пользователя, берёт его email и отсылает письмо - что недопустимо и грязно. Вот где та граница, что можно писать в листенеры а что нет?

хорошо, а кто-то взял и прописал то же событие но не в доктрин ивенты а в terminate кренела? так уже можно?

Не понимаю чем плох глагол для инвока AddUser, в тему про нейминг и "нельзя глаголы"

Не понимаю чем плох глагол для инвока AddUser, в тему про нейминг и "нельзя глаголы"

Просто с invokable классами проще решать проблему нейминга, существительное гораздо сложнее выходит, приходится использовать "ненужные" суфиксы UserRegistrationHandler->handle(), что повышает когнитивную нагрузку )

Просто с invokable классами проще решать проблему нейминга, существительное гораздо сложнее выходит, приходится использовать "ненужные" суфиксы UserRegistrationHandler->handle(), что повышает когнитивную нагрузку )