Лучше на котлин. Чайка не даст соврать

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

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

плюс есть сборки в которых некоторые модули буквально не нужны

Так навесь стат анализ с правилами

> повесить кернел сабскрайбер и не писать 400 раз is json ? is json ? is json ?

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

недавно на редите видел тулзу для "раскраски"...

да, симфони в этом плане конечно уебищное говно то еще

ну не только, пишу же не хочу чтобы на реквест прогонялось 400 ->supports?

можно обойти через проверку там на маркер* интерфейс (ой маркер для дтошки) или что еще, сделать один

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

а нахер тебе сктолько парам резолверов?)

в целом померяй - может быть 400 вызовов не такая уж и большая проблема

большое апи, хочется дтошки на разные запросы, с них строить валидаторы и доку

для этого хватит одного аргумент ресолвера

ну я не думаю что 400 ифов это конец жизни

и плюс это аплаенс а не паблик апи какое-то

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

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

еще раз - тебе НЕ нужно на каждый роут делать отдельный ресолвер ТОЛЬКО для того что бы замэпить json на dto

нет я понимаю