Почему интеграции «в лоб» становятся хрупкими

Когда сайт обращается к 1С или CRM напрямую из бизнес-логики, эта логика намертво срастается с чужим API: его форматом, его ошибками, его поведением. Меняется внешний сервис — приходится переписывать код, который к самому бизнесу отношения не имеет.

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

Use case: сценарий обмена на языке бизнеса

В основе устойчивой интеграции — бизнес-сценарий: «передать заказ в учётную систему», «синхронизировать остатки», «отправить лид в CRM». Он описывает, что нужно сделать, и ничего не знает про конкретный протокол или формат.

Это та же идея, что в статье про DDD: логика отделена от инфраструктуры. Здесь она помогает сделать обмен предсказуемым и тестируемым.

Порт: контракт с внешним миром

Порт — это контракт: что системе нужно от внешнего мира, выраженное простыми словами. Например, «хранилище заказов умеет сохранить заказ» или «сервис CRM умеет принять заявку». Бизнес-сценарий работает с этим контрактом, а не с конкретным API.

Благодаря порту бизнес-логику можно проверять с «заглушкой» вместо реальной 1С — это ускоряет разработку и делает тесты надёжными.

Адаптеры: 1С, CRM, оплата, доставка, очередь

Адаптер — это конкретная реализация порта под конкретный сервис. Адаптер для 1С знает её формат, адаптер для AmoCRM — её API, адаптер для оплаты — её протокол. Все они подключаются к одному и тому же порту.

Поэтому сменить CRM или добавить новую систему — это написать новый адаптер, а не переписывать бизнес-логику. Для бизнеса это прямая экономия и снижение риска при смене подрядных сервисов.

Повторы, логирование и контроль результата

Повторные попытки: временный сбой внешней системы не теряет данные.
Очереди: обмен идёт надёжно и не тормозит оформление заказа.
Логирование: видно, что и когда ушло во внешнюю систему и с каким результатом.
Идемпотентность: повтор не создаёт дубликатов заказа или клиента.
Мониторинг: понятно состояние обмена, а не «вроде работает».

Что получает бизнес

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