Symfony-проект тонет не от DI, а от слабых границ между слоями
В Symfony легко собрать «аккуратный монолит», который через пару спринтов превращается в клубок сервисов. Первый маркер: контроллер знает про EntityManager, форму, внешнее API и бизнес-правило одновременно. Контроллер должен принимать запрос, вызвать сценарий, вернуть ответ. Всё остальное — запах.
Мини-чек-лист для ревью:
— сервис приложения не возвращает Request/Response;
— доменная логика не живёт в FormType и EventSubscriber;
— Doctrine-сущность не ходит в контейнер и не отправляет письма;
— команда Messenger идемпотентна: повторный запуск не ломает данные;
— параметры из env доходят до кода через конфиг, а не через getenv() в середине метода.
Есть наблюдение которое стоит проверить: чем больше «магии» в autowire, тем важнее явные имена сервисов на границах. Для платежей, трекеров, CRM-интеграций и очередей лучше иметь интерфейс + конкретный адаптер.
Symfony хорошо держит долгие коммерческие проекты, если не использовать framework как склад для любой логики. Держите сценарии отдельно, инфраструктуру отдельно, а контроллеры скучными.
Laravel & PHP Deep — фреймворки и пакеты
@laravel_php_deep
Symfony-проект тонет не от DI, а от слабых границ между слоями
Этот пост опубликован в Telegram-канале Laravel & PHP Deep — фреймворки и пакеты. Подписаться можно по ссылке: @laravel_php_deep.