Юркас
Платформа
Год развиваем e-com-ядро Yurkas. Продажи не останавливались ни на день
Для Yurkas, белорусской розничной сети дверей и материалов, мы переписываем ядро конфигуратора товаров со сложной доменной логикой. Новая архитектура растёт параллельно с действующей системой — продукт продолжает приносить выручку.
развивать критичный для бизнеса продукт без права на остановку
к нам пришла не новая разработка, а живая e-commerce-система с накопленным наследием — и с дневной выручкой, которую нельзя поставить на паузу.
[ запрос ]Развивать и стабилизировать конфигуратор товаров — модуль, через который Yurkas продаёт двери, фурнитуру и сопутствующие материалы. У клиента нет собственной команды разработки. Проект пришёл с накопленным наследием от предыдущих этапов работы — со сложной доменной логикой и техническим долгом, который мешал развитию.
[ вызов ]Сделать это, не остановив продажи. Доменная модель сильно связана: один атрибут влияет на номенклатуру, фильтры, совместимость, цены и внешние интеграции. Ежеминутно пересчитываются миллионы товарных моделей. Цена ошибки в этой системе исчисляется миллионами.
можно было переписать с нуля. Мы выбрали путь сложнее, но безопаснее для бизнеса
[ путь 1 ]Переписать с нуля
Привычное решение для систем с накопленным техдолгом. Звучит быстрее на бумаге. На практике это означает остановку работающего конфигуратора на время миграции — потерю продаж, операционный простой, риск, что миграция данных пойдёт не так. Для системы, через которую идёт ежедневная выручка, это слишком дорогой эксперимент.
развивать рядом
Новая архитектура строится параллельно с действующей системой. Старый конфигуратор продолжает продавать, пока команда переносит модули по одному. Каждый перенос — отдельный управляемый шаг с возможностью отката. Это медленнее на бумаге, но единственный путь для продукта, у которого нет права на остановку.
сделать быстро — задача подрядчика. Не уронить бизнес — задача партнёра
бизнес не заметил, что у него меняют ядро
старая система продаёт Новая — растёт рядом
- 01Сохраняем то, что работаетДействующий конфигуратор остаётся источником продаж до тех пор, пока новая версия не закроет его функциональность полностью. Не трогаем то, что прямо сейчас приносит выручку клиенту.
- 02Строим новое рядомКаждая бизнес-область — каталог, цены, комплекты, интеграции — живёт в своём изолированном пространстве со своими правилами. Связи между ними становятся явными.
- 03Переносим по одной страницеКаждый перенос — отдельный управляемый шаг. Сначала готовим новую версию модуля, тестируем её рядом со старой, потом переключаем трафик. В любой момент можно откатиться.
- 04Развиваем параллельноПока идёт миграция, продукт продолжает развиваться: добавляются новые правила ценообразования, сценарии, интеграции. Новая архитектура изначально проектируется под то, чтобы вмещать развитие.
этот подход выдерживает даже паузы в коммуникации, естественные для компаний без внутренней команды разработки Бизнес продолжает работать, а команда — двигаться вперёд по своему графику
архитектура, которая выдержит развитие
новая архитектура проектируется под то, чтобы прожить столько, сколько потребуется продукту, и принимать в себя новые правила без структурной перестройки
domain-driven design
Бизнес-логика вынесена в доменные модули с чёткими границами. Изменение правила в одном месте больше не означает риск для десятков смежных компонентов.
[ Что это даёт ]- — Новый функционал добавляется внутрь одного модуля, а не размазывается по всей системе.
- — Связи между доменами становятся явными и управляемыми.
- — Команда видит, где заканчивается одна предметная зона и начинается другая.
асинхронные очереди
Тяжёлые операции — массовый пересчёт цен, генерация номенклатуры, синхронизация — выведены в фоновую обработку через RabbitMQ. Пользовательские сценарии больше не блокируются.
[ Что это даёт ]- — Покупатель не ждёт, пока система пересчитывает то, что должна была посчитать ночью.
- — Тяжёлые задачи запускаются в рабочие часы без риска положить систему.
- — Можно горизонтально масштабировать обработку без переделки кода.
Современный, проверенный стек, подходящий для долгого развития. Без экспериментальных решений — где работает бизнес клиента, нет места для технологических ставок.
наблюдаемость и аудит
С нуля разработана страница системных уведомлений. Введены роли админов и суперадминов. Команда клиента видит, что происходит внутри системы, и может вмешаться до того, как ошибка дойдёт до покупателя.
[ Что это даёт ]- — Любое подозрительное событие фиксируется и проверяется.
- — Изменения в критичных зонах (цены, совместимость, номенклатура) контролируются.
- — Снижается риск того, что ошибка станет видна только из жалобы клиента.
управляемая миграция
Каждый перенос модуля начинается с того, что новая версия поднимается рядом со старой и тестируется на реальном трафике без переключения. Только после того, как она показывает себя стабильно, на неё переводится поток. Старая система остаётся горячим резервом — на случай неожиданного поведения новой.
[ Что это даёт ]- — Команда видит поведение новой версии в реальных условиях до того, как она становится боевой.
- — Изменения происходят постепенно, без эффекта «большого взрыва».
- — Команда клиента может проверять каждый перенос до того, как он станет необратимым.
- Страница системных уведомленийРазработана с нуля. Фиксирует критичные события и нештатные сценарии — операторы видят их раньше, чем они доходят до покупателя. Заменяет жалобу клиента как способ узнать о проблеме.
- Ролевая модельВведены роли админов и суперадминов с разделением прав. Изменения в критичных зонах системы — ценах, совместимости, номенклатуре — требуют соответствующих полномочий.
год работы: ядро конфигуратора и всё, что рядом
основная работа шла над ядром конфигуратора. Параллельно команда закрывала смежные технические задачи — там, где у клиента не было других подрядчиков.
[ Ядро системы ]- Перенос страниц конфигуратораПоловина ключевых страниц переведена со старой версии на новую архитектуру. Работа продолжается — оставшиеся переносятся поэтапно, с переключением трафика только после прохождения проверок.
- Платформа для тяжёлых операцийМассовый пересчёт цен, генерация номенклатуры и синхронизация с внешним учётом выведены в очереди RabbitMQ. Поддержаны сценарии расчёта будущих цен и массовая фоновая обработка товарных позиций.
- SSO для NextcloudРеализована единая авторизация через OAuth2: синхронизация ролей, управление папками, автоматический выход при смене пароля. Передана техническая документация для администраторов.
- Telegram-бот для поиска номенклатурыAI-помощник в Telegram для поиска по номенклатуре Бот на базе LLM помогает менеджерам и клиентам находить товары в каталоге на естественном языке — без точных артикулов. Понимает синонимы, нестрогие запросы, уточнения в диалоге. Точность поиска около 90%
что изменилось в системе после миграции на новую архитектуру и переработки самых тяжёлых операций
за год работы команда переписала ядро конфигуратора Yurkas на новую архитектуру, перенесла около половины ключевых страниц, вывела тяжёлые операции в асинхронную обработку и уложила потребление ресурсов в десятки раз меньше прежнего.
- память воркеров RabbitMQУстранены десятки утечек памяти, накопленных за историю проекта
- тяжёлые запросыПосле перехода на контейнеризацию и оптимизации обработки
- скорость APIПо разным эндпоинтам — в зависимости от типа операции
- память на отдельных запросахНа самых тяжёлых операциях пересчёта
что это значит для бизнеса
- ЭффективностьТа же инфраструктура держит больше — система не упирается в железо по мере роста.
- ОптимизацияСценарии, которые раньше нельзя было запускать в рабочие часы, теперь идут в фоновом режиме за секунды.
- Готовность к ростуЗапас прочности для роста бизнеса — архитектура выдержит больше товаров, цен, заказов без необходимости снова трогать ядро.
продукт продолжает приносить выручку
архитектура — готова к следующему этапу развития
давайте обсудим ваш проект
В течение 24 часов с вами свяжется специалист, чтобы уточнить детали и обсудить следующие шаги. Если вопрос срочный — пишите директору напрямую.
KIT 4 KID
смотреть кейс