Альтернативный способ структурировать проект Symfony

Архитектура MVC + Services давно стала стандартом в проектах Symfony. Она проста, знакома и обычно эффективна, но с ростом сложности проекта начинают проявляться слабые места: бизнес-логика оказывается разрозненной, поведение приложения становится неочевидным, а поддержка кода превращается в проблему. Хотя Symfony не ограничивает вас этой архитектурой, многие разработчики воспринимают её как единственный вариант.

Проблемы MVC + Services в больших проектах
🔸Разрозненная бизнес-логика
По мере роста проекта бизнес-логика распределяется между контроллерами, сервисами, формами, сущностями и другими слоями. Это усложняет работу с кодом, поскольку каждый слой содержит лишь часть общей модели.

🔸Размытые границы между контекстами
Когда архитектура строится вокруг технических слоёв, становится сложно определить чёткие границы между различными областями проекта. Это приводит к сильной связанности кода и затрудняет его поддержку.

🔸Неявное поведение приложения
Структура кода в MVC + Services не даёт ясного понимания, что именно делает приложение. Сложно выявить ключевые действия проекта без анализа множества файлов и зависимостей.

🔸Смешанные жизненные циклы
Бизнес-логика обычно живёт дольше, чем реализации, такие как API, базы данных или фреймворки. Смешение логики с деталями реализации приводит к тому, что даже небольшие изменения требуют переработки большого объёма кода.

Альтернативный подход: архитектура с выделением бизнес-логики
1. Изоляция бизнес-логики
Первый шаг — выделение бизнес-логики в отдельную папку Domain, которая становится ядром проекта. Эта папка содержит чистые PHP-объекты, не зависящие от фреймворков или библиотек. Внутри папки файлы группируются по логическим функциям, а не техническим слоям.

2. Определение «входной двери» проекта
Создайте папку Application, которая явно описывает все действия и возможности приложения. Это поможет новым разработчикам быстро понять, что может проект.

3. Работа с внешними системами
Реализация интеграции с фреймворками, базами данных и другими системами выносится в папку Infrastructure. Она зависит от файлов в папках App и Domain, но не наоборот.

4. Выявление и разделение контекстов
Если понятия, такие как «Продукт», имеют разные значения в разных частях проекта (например, товар на складе и товар в магазине), их нужно разделить на отдельные контексты с независимой бизнес-логикой.

Эволюция архитектуры

🟢Модульность и границы
Если какой-то модуль проекта разрастается, его можно выделить в отдельный деплоймент. Но это стоит делать только при необходимости, например, если команды сталкиваются с трудностями совместной работы.

🟢Систематизация кода
Архитектуры, такие как Hexagonal, Onion, и Clean, помогают изолировать бизнес-логику от деталей реализации. Это делает тестирование проще и код более устойчивым к изменениям.

🟢«Говорящая» структура проекта
Структура файлов должна «кричать» о том, что делает приложение. Организация кода должна быть интуитивно понятной и отражать функциональность проекта.