<b>Symfony ломают не роуты, а границы слоёв: 5 мест, где проект течёт</b>

<b>Symfony ломают не роуты, а границы слоёв: 5 мест, где проект течёт</b>

Если Symfony начинает казаться «тяжёлым», причина часто не в фреймворке, а в том, что в одном месте смешали HTTP, бизнес-логику и доступ к данным. В итоге контроллеры разрастаются, сервисы дублируют друг друга, а тесты проверяют не поведение, а случайный набор вызовов.

Проверьте 5 типовых зон:
— контроллер должен принимать запрос и отдавать ответ, а не считать скидки;
— сервис не должен знать про Request и Session;
— репозиторий не обязан решать, кому и что показать;
— DTO лучше отделять от Entity, если данные приходят извне;
— консольные команды и события не должны содержать бизнес-логику «на крайний случай».

Ещё одна частая ошибка — цеплять всё к контейнеру через автосборку и считать это архитектурой. DI полезен, пока зависимости читаются глазами. Если класс тянет 12 сервисов, это обычно сигнал разрезать сценарий на части и вернуть явные границы.

Хорошая проверка проста: если доменную операцию нельзя описать одной фразой без слова «контроллер», слой уже перепутан. Разведите роли раньше, чем проект начнёт тормозить на любом изменении.