В чём проблема типичного Bitrix-проекта
В Bitrix-проектах бизнес-логика часто оказывается размазанной: часть в компонентах, часть в шаблонах, часть в обработчиках событий и прямых вызовах API. Когда логика заказа или расчёта цены живёт в десяти местах, любая доработка становится рискованной — правка в одном месте неожиданно ломает другое.
Это и есть корень «хрупкости»: сроки растут, новые разработчики долго входят в проект, а бизнес боится трогать то, что «и так работает». DDD предлагает не магию, а способ навести порядок — постепенно и без остановки.
Ограниченный контекст: язык, понятный бизнесу
Базовая идея DDD — выделить ограниченные контексты: области, у которых есть свой понятный язык и свои правила. В интернет-магазине это, например, каталог, заказ, клиент, доставка. Внутри каждого контекста слова значат одно и то же и для бизнеса, и в коде.
Такое разделение само по себе снижает путаницу: «заказ» в контексте оформления и «заказ» в контексте доставки перестают смешиваться, а границы между модулями становятся явными.
С чего начать: выбрать первый безопасный участок
Вводить DDD сразу везде не нужно и опасно. Начинают с одного участка — критичного, но обозримого. Хороший кандидат: логика, которая часто меняется и приносит больше всего ошибок, но при этом её границы понятны (например, расчёт стоимости заказа).
Use case как точка входа в бизнес-сценарий
Use case — это сценарий бизнеса, выраженный в коде: «оформить заказ», «рассчитать доставку», «применить скидку». Он описывает, что должно произойти, на языке бизнеса, и не зависит от того, как именно это вызвано — из Bitrix-компонента, из API или из фоновой задачи.
Когда логика собрана в use case, её легко тестировать и переиспользовать, а компонент Bitrix становится тонкой «обёрткой», которая просто вызывает сценарий и показывает результат.
Как не сломать старый код: адаптеры вокруг Bitrix
Чтобы не зависеть от Bitrix API внутри бизнес-логики, его прячут за адаптерами. Доменный код работает с понятными контрактами («получить товар», «сохранить заказ»), а конкретные вызовы Bitrix живут в инфраструктурном слое.
Это и позволяет двигаться без переписи: старый код продолжает работать, новые сценарии подключаются рядом, а переключение идёт итерациями. Подробнее про тонкие компоненты и про порты и адаптеры — в соседних статьях этого блога.