Что нового на пути Docpart к Symfony

20.03.2026

Продолжается долгая и сложная работа по переходу нашей CMS для магазинов автозапчастей Docpart на PHP-фреймворк Symfony. О том, какие возможности и преимущества для наших пользователей это даст, мы уже рассказывали в предыдущих публикациях. А сегодня хотим поделиться с вами новостями о том, что нового и интересного было на этой неделе в процессе решения данной задачи - переезда Docpart на Symfony.

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

Задача по переходу на Symfony, несомненно, самая сложная с технической точки зрения, из всех, которые нам приходилось решать за все время существования Docpart. Перенос зрелого проекта на полностью новую техническую архитектуру - задача, которая требует от разработчиков высокой квалификации и больших усилий. Однако насколько данная задача сложна, на столько же она и интересна. Поэтому, мы скорее испытываем большой профессиональный интерес, а вовсе не трудности.

Итак к новостям.

DDD - разделение на чистую архитектуру

Недавно мы сообщали о выборе DDD в качестве подхода к проектированию архитектуры самого веб-приложения. Затем по мере погружения в тему, возникали сомнения в целесообразности настолько детального разделения архитектуры на слои - ведь Symfony уже дает достаточно неплохие MVC подходы в разработке кода, а именно разделение кода на классы контроллеров, сервисов, сущностей (Entity) с готовой ORM и т.д. Не стала бы еще большая детализация (бизнес-логика отдельно, техническая логика отдельно) избыточной?

Анализировать это можно было долго. Мы просто попробовали на примере одной модели. Оказалось, что полное отделение бизнес-логики в изолированный код, дает разработчику возможность даже не задумываться о последующей технической реализации, которая в итоге так и останется делом техники, не требующим больших усилий. В общем подход DDD, который некоторые разработчики критикуют за излишнюю сложность, в случае с такими проектами, как Docpart (много функционала и возможность развития на годы вперед), полностью себя оправдывает. Да, порог входа выше (требуется большая квалификация программистов, больший опыт и осмысленное поведение), но и качество самого продукта получается уже совсем другого порядка.

В итоге, мы убедились в правильности выбора и целесообразности применения DDD. Это нам дает:

• чистую архитектуру (бизнес логика отдельно, техника отдельно - Domain, Application, Infrastructure)
• возможность использовать модули Docpart отдельно (к примеру, разрабатываемый модуль складского учета можно будет легко выделить в отдельный продукт)
• возможность менять технические решения и рефакторить код без полного переписывания
• независимость модулей друг от друга - меняя один модуль, например, каталог, не придется менять ни один другой модуль (корзину, заказ, проценку и т.д.)

Шаблоны дизайна

Окончательно проработана архитектура шаблонов дизайна. Фреймворк Symfony использует шаблонизатор Twig, который предоставляет мощнейшие возможности построения шаблонов с полноценным применением принципов MVC. Это позволит нам чаще выпускать новые шаблоны и расширять выбор тем для наших клиентов. Кроме того, любой разработчик дизайна (Sigma/PS/HTML-CSS-JS) сможет легко добавлять свои шаблоны, ведь шаблонизатор Twig и фреймворк Symfony очень хорошо задокументированы.

Более того, и, пожалуй самый приятный момент по дизайну: сегодня можно найти тысячи готовых шаблонов для Symfony, что расширяет возможности кастомизации дизайна Docpart настолько, что ранее это даже нельзя было представить. В виду популярности Symfony и признания его лучшим фреймворком мира, сегодня любой уважающий себя разработчик дизайна, выпуская очередной свой шаблон, комплектует его в том числе пакетом под Symfony, так, что его даже не требуется как-то дополнительно адаптировать - перечень файлов *.html.twig уже идет в сборке таких шаблонов. Готовя эту новость к публикации, не предполагалось проявлять эмоции, т.к. новость сугубо технического характера, но, для Docpart это, по сути, настоящий прорыв в возможностях расширения дизайна.

Временные модули синхронизации с legacy-кодом

Поскольку Docpart - это уже сложившийся проект с большой историей и сотнями разных функций, встал вопрос, как обеспечить одновременную работу старой (legacy) архитектуры и нового фреймворка на этапе между тем, когда первые функции станут доступны на Symfony и тем, когда все функции полностью будут на Symfony. Не трудно догадаться, что на этом этапе, какая-то часть функций будет продолжать работу на старой архитектуре Docpart до их полного постепенного переезда на Symfony. Базовую задачу по интеграции ядра Docpart и Symfony мы решили практически сразу, буквально за один день. А вот синхронизация более высокоуровневых функций, таких, как например, аутентификация пользователей, проверка прав, управление сессиями и др. требовалось решать более тщательно.

Чем это обусловлено? К примеру, пользователь зашел на сайт под своей учеткой, находясь на странице, работающей уже под Symfony. А затем с этой страницы перешел на старый модуль, который пока работает на старом ядре. Как сделать так, чтобы ему не пришлось заново залогиниваться ухудшая пользовательский опыт? Вот для таких целей и мы создали временные модули взаимодействия между Symfony и старым кодом. Благодаря этому, пользователь даже не замечает, что разные страницы одного сайта управляются разными архитектурами. Ну, разве что, страницы на Symfony открываются заметно быстрее.

На сегодня пока все новости. Продолжаем держать вас в курсе нашей работы.