Как компания ушла от монолита и что это дало бизнесу

В разработке есть момент, который наступает почти неизбежно: бизнес хочет больше скорости и больше возможностей, а платформа на это не рассчитана. Тогда приходится искать элегантные решения, принимать компромиссы и иногда приручать черного лебедя. На одном из таких поворотов мы и оказались с проектом на монолитной архитектуре.

Меня зовут Евгений Шарыпов, я руковожу направлением веб-разработки программных систем в ИТ‑компании ARTW.

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

В этой статье разберу на примере одного из наших проектов, как мы ушли от монолитной архитектуры и пришли к API‑First подходу и что это дало бизнесу.

Почему монолит перестает устраивать

В типовом проекте на Битрикс все живет внутри одного монолита — CMS: витрина, каталог, корзина, интеграции, платежи. Такой подход долго был стандартом. Он быстро запускается, предсказуем в поддержке и нормально работает, пока бизнес развивается в одном канале и меняется умеренно.

Но связность монолита быстро становится ограничением. Любое изменение — от баннера до новой карточки товара — требует релиза всей системы. В итоге скорость бизнеса начинает зависеть не от маркетинга, а от скорости разработки и от того, насколько рискован очередной релиз.

Примерно такая инфраструктура была у одного из наших проектов — интернет-магазинов Concept Group.

Отправная точка — несколько интернет‑магазинов на «Битрикс: Управление сайтом» + CRM в режиме многосайтовости. За это время были сформированы устоявшиеся процессы, понятные сценарии. Проект развивался несколько лет и накопил приличный груз кодовой базы. Новые функции делались все медленнее. Главная причина — связность кода в шаблонах и компонентах. Современные требования к пользовательской части мы закрывали не полностью: монолит и серверное формирование страниц не давали раскрыть потенциал современных технологий разработки.

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

Решение

Мы разделили слои. Ядро оставили стабильным на Битрикс: оно отвечает за данные, цены, остатки, бизнес‑процессы и интеграции. Витрина стала самостоятельной: получает данные по API и меняется столько раз, сколько нужно бизнесу, без правок в серверной части «по мелочам». Пользовательскую часть мы реализовали на стеке Vue3 + Nuxt3.

Смысл простой: внешняя часть развивается в своем темпе и не задевает критичные процессы на стороне серверной части. При этом внутренняя часть может представлять собой как монолитное решение, так и распределенную сервисную архитектуру — снижая зависимость от технологий и стека. Эта независимость и делает такой подход, который не замедляет рост, а подстраивается под него.

Чтобы серверная и пользовательская части «говорили на одном языке», мы начали с контракта. Описали его в Swagger: какие данные предоставляются и через какие точки доступа REST API. Это и был первый шаг к API‑First. После этого команды смогли работать параллельно и не тратить время на «давайте потом уточним формат».

Затем мы зафиксировали структуру ответов на серверной части. Для этого описали DTO‑модели — простой слой между контроллерами и ответами REST API.

Отдельно расскажу про контроллеры REST API. В Битриксе многие вещи уже реализованы через компоненты, и часть компонентов написана как классы. Их можно наследовать и использовать повторно в наших API‑методах. Мы так и сделали. Например, фасетный фильтр построили на базе bitrix:catalog.smart.filter. То есть мы не переписывали проверенный функционал, а аккуратно переиспользовали его.

Битрикс поддерживает виртуальные сессии. Поэтому мы смогли использовать возможности ядра Bitrix Framework без дополнительных обходных решений. Это снижает стоимость перехода и уменьшает количество самописного кода.

Для управления контентом страниц мы взяли бесплатный модуль из маркетплейса — sprint.editor. Он расширяемый, а набор контентных блоков не ограничен. Структуру данных блоков мы тоже зафиксировали в контракте. В итоге каждый блок в админке стал соответствовать Vue‑компоненту во внешней части: контент‑менеджер работает в привычном интерфейсе, а витрина получает предсказуемые данные.

С точки зрения админки сайта и CRM ничего не поменялось. Контент‑менеджеры и администраторы работают так же, как работали раньше, без смены привычных сценариев.

Вся бизнес‑логика осталась в Bitrix Framework. Поэтому платформу можно обновлять спокойно. Мы не вмешиваемся в ядро и не превращаем каждый апдейт в отдельный проект.

Выводы

В итоге мы получили устойчивое решение, которое не затрагивает ядро Bitrix Framework и при этом поддерживает API‑First подход. Для бизнеса это означает продукт на современных рельсах, но без ломки привычных процессов в админке и CRM.

Для разработчиков Bitrix Framework закрывает базовые потребности для REST API: можно развивать сервисный слой, фиксировать контракт и спокойно масштабировать точки входа. Веб‑витрина, личный кабинет, мобильное приложение — все это можно строить на одном ядре, не дублируя бизнес‑логику. При этом пользовательская часть живет своей жизнью: меняется быстро и часто, а критичные процессы во внутренней части остаются стабильными.

Для сотрудников бизнеса плюс в том, что рабочие инструменты не меняются. Контент‑менеджеры и администраторы остаются в знакомой панели, но получают более гибкую витрину и предсказуемые блоки. Маркетинг и продукт меньше зависят от «больших релизов»: часть задач решается на пользовательской части быстрее и безопаснее.

И главный эффект для компании — скорость без потери надежности. Вместо релиза «всего сайта» ради одного изменения на витрине появляется управляемая схема, где каждый слой развивается в своем темпе, а бизнес получает больше изменений за то же время и с меньшими рисками.