Symfony решает, нужен ли фреймворку собственный ORM

27 октября 2026 года в репозитории symfony/symfony на GitHub появился RFC «Evaluate a Symfony ORM component against enterprise persistence requirements» — автор предлагает обсудить, нужен ли фреймворку собственный ORM-компонент рядом с Doctrine, который используется по умолчанию. Официальный еженедельный дайджест A Week of Symfony #1035 отдельно подтвердил этот RFC в списке активных обсуждений за неделю 26 октября — 1 ноября — источники независимы и сходятся в формулировке и дате.

Речь не о замене Doctrine целиком. В тексте RFC прямо говорится: сегодня нужные возможности закрываются связкой Doctrine, DBAL, сторонних расширений и кода самого приложения. Вопрос в том, оправдывает ли это выделение отдельного компонента symfony/orm, который переиспользовал бы DBAL там, где это уместно, и не ломал бы границы для приложений, которые ORM вообще не используют.

Чем, по мнению автора, не хватает Doctrine

RFC ссылается на возможности, которые есть у Hibernate в Java-экосистеме и которые Doctrine ORM не закрывает через сопоставимый публичный API — сложные стратегии наследования, более тонкий контроль над unit of work и батчингом запросов. Сейчас такие вещи команды добирают вручную: прямыми запросами через DBAL, кастомными hydrator'ами, отдельными слоями поверх репозиториев. Со временем это расходится по проекту и превращается не в осознанную архитектуру, а в накопленный технический долг.

Что это значит для проекта сейчас

RFC — это стадия обсуждения, а не анонс релиза: до появления symfony/orm в composer.json пройдёт не один цикл, если решение вообще примут в эту сторону. Но сам факт, что ядро фреймворка публично признаёт разрыв между Doctrine «из коробки» и требованиями enterprise-персистентности, — сигнал для тех, кто сейчас проектирует слой данных нового веб-приложения: стоит заранее зафиксировать, где заканчивается ответственность ORM и начинается явный код приложения, а не откладывать этот вопрос до первой проблемы с производительностью или консистентностью.

Похожие обсуждения в экосистеме Symfony и раньше тянулись годами, прежде чем доходили до релиза — тот же ход видно и по текущему дайджесту проекта: за неделю, пока открывали этот RFC, команда одновременно выпустила четыре плановых maintenance-релиза (5.4.55, 6.4.49, 7.4.22, 8.1.10) и влила 344 pull request, то есть ресурс на крупные архитектурные инициативы распределяется параллельно с текучкой, а не вместо неё. Практически это значит, что даже при положительном решении по RFC компонент сначала пройдёт через несколько минорных версий в экспериментальном статусе — закладывать его в архитектуру проекта на 2027 год рано, но держать в уме как направление развития платформы уже стоит.

• Проверить, где в проекте Doctrine уже обходят кастомным кодом — это кандидаты на будущую миграцию, если RFC дойдёт до реализации
• Не завязываться жёстко на внутренние API Doctrine там, где достаточно интерфейса репозитория — это снизит стоимость любого будущего решения по persistence-слою
• Следить за статусом issue #67534 перед тем, как проектировать слой данных для нового крупного модуля — обсуждение может закончиться и компонентом, и отказом от идеи

Для проектов, где слой данных уже разросся до состояния, которое мешает релизам, ждать развязки этого RFC необязательно: решение о границах ORM, репозиториев и доменной модели можно и нужно принимать сейчас. Мы писали о похожих архитектурных развилках в материале «Гексагональная архитектура в PHP», а когда слой персистентности пора пересобрать с нуля под конкретный стек и нагрузку, это обычная часть YuSMP Group — разработку веб-приложений там ведут с таких же архитектурных развилок, а не постфактум.