<b>Symfony ломается не в контроллере, а на границе между слоями</b>

<b>Symfony ломается не в контроллере, а на границе между слоями</b>

В проектах на Symfony чаще всего течёт не «фреймворк», а архитектурная дисциплина. Контроллер должен собирать вход, вызвать сервис и вернуть ответ; всё остальное уезжает в доменный слой, форму или отдельный handler. Как только в action появляются SQL, условные ветки по ролям и сборка HTML — код перестаёт быть тестируемым.

Есть три места, где стоит держать порядок:
— Request DTO или Form: валидация и нормализация входа
— Service/UseCase: бизнес-правило без HTTP-зависимостей
— Repository: только доступ к данным, без магии и сайд-эффектов

Ещё одна типовая ошибка — тащить container везде, где удобно. В Symfony это особенно соблазнительно, потому что сервисы рядом, но зависимость через контейнер скрывает контракт и усложняет тесты. Лучше явно прокидывать интерфейсы и держать сервисы маленькими: один класс — одна причина для изменения.

Если нужен быстрый аудит проекта, проверьте: есть ли у контроллеров только orchestration, можно ли поднять use case без ядра HTTP, и есть ли у каждого сервиса понятная зона ответственности. Там, где ответ «нет», и прячется будущий рефакторинг.