Интеграция — это способ связать независимые системы для обмена данными и функциональностью. На проекте выбор архитектурного стиля интеграции (точка-точка, ESB, API-led) определяет, как вы описываете интерфейсы, какие нефункциональные требования (НФТ) закладываете и какой технический долг принимаете. Эта заметка даёт классификацию трёх базовых паттернов, их компромиссы и критерии выбора; протоколы, контракты и безопасность — в соседних статьях раздела 03.05.

1. Суть темы

Интеграция в контексте системного анализа — не протокол и не формат данных, а архитектурное решение о том, кто с кем и через что общается. Три паттерна из заголовка отвечают на разные вопросы топологии:

ПаттернСутьВопрос, который закрывает
Точка-точка (Point-to-Point, P2P)Прямое соединение каждой пары систем«Как быстро связать две системы?»
ESB (Enterprise Service Bus)Централизованный посредник (middleware)«Как управлять десятками гетерогенных систем через единую шину?»
API-led ConnectivityТрёхслойная продуктовая модель API (System → Process → Experience)«Как структурировать API для повторного использования и омниканальности?»

Важное различение: API-led и ESB не являются взаимоисключающими альтернативами. API-led описывает слои и жизненный цикл API; ESB/iPaaS — механизм медиации, маршрутизации и оркестровки. На практике Process API часто реализуют тем же ESB, BPM-движком или оркестратором, а System API разворачивают поверх legacy — в том числе через интеграционную платформу. Смешивать «легковесная альтернатива ESB» с «три слоя API» — типичная логическая ошибка.

Параллельно с паттернами топологии существуют цели интеграции — это другая ось классификации:

  • Информационная — обмен данными (репликация, CDC, события, файловый/batch-обмен по FTP/SFTP).
  • Функциональная — вызов удалённых сервисов (RPC, REST, SOAP).
  • Пользовательская — единый интерфейс поверх нескольких систем (порталы, mashup); ближе к каналам и UX, см. 03.01.04 Интерфейсы и интеграционные взаимодействия.

Цель интеграции не равна архитектурному паттерну: один и тот же batch-обмен может идти по P2P (CSV по FTP), через ESB или через System API.

Ключевые вызовы, влияющие на выбор паттерна:

Выбор паттерна напрямую связан с НФТ (08.02 Нефункциональные требования (НФТ) — классификация и стандарты) и часто фиксируется в ADR (10.01.13 Шаблон архитектурного решения (ADR)). Как реализовать сквозной процесс — оркестрация или хореография — решается отдельно (03.05.06 Event-Driven Architecture).

2. Ключевые понятия

2.1. Интеграция «точка-точка» (Point-to-Point)

Каждая пара систем соединяется напрямую выделенным каналом со своим протоколом и форматом.

graph LR
    A[CRM] -- "REST/JSON" --> B[Биллинг]
    A -- "SOAP/XML" --> C[Склад]
    B -- "JDBC" --> D[БД отчётов]
    C -- "CSV по FTP" --> D
    C -- "REST" --> A
    B -- "Email" --> E[Уведомления]

Плюсы: простота на старте, минимальная инфраструктура, прямой контроль над каждой парой.

Минусы: при полной связности N систем число соединений растёт как N(N−1)/2 — «спагетти-архитектура»; на реальных ландшафтах граф реже полный, но тренд тот же. Хрупкость при изменениях, дублирование логики (трансформация, безопасность), отсутствие единой точки наблюдения, жёсткая связанность (tight coupling).

Файловая и batch-интеграция — массовый корпоративный паттерн (выгрузки, ETL, обмен по расписанию). На схеме выше CSV/FTP — типичный P2P-канал; в сравнительной таблице ниже batch учитывается как сценарий, а не отдельный «четвёртый вид».

Когда уместно: 2–3 системы, пилот, временное решение с явным техдолгом, узкий high-performance канал (иногда с асинхронными очередями — 03.05.04 Асинхронное взаимодействие (очереди, Kafka, Events)).

2.2. Упрощённая «звезда»: hub-and-spoke (не четвёртый вид)

Между P2P и полноценным ESB часто встречается hub-and-spoke — простой центральный брокер (очередь, FTP-сервер, lightweight message broker) без богатой медиации. Число связей — N вместо N(N−1)/2, но трансформации и оркестровка остаются на стороне систем.

Это не четвёртый архитектурный вид, а упрощённая топология «звезды» на пути к ESB: тот же ADR-выбор «централизованная медиация», но без канонических форматов, оркестрации и governance полноценной шины. В чеклисте и таблице ниже hub-and-spoke отражён как промежуточный сценарий между P2P и ESB, а не равноправный паттерн наряду с API-led.

2.3. Сервисная шина предприятия (ESB)

ESB — централизованное middleware, модель «звезда». Системы подключаются к шине; она берёт на себя маршрутизацию, преобразование форматов, оркестровку, мониторинг, гарантированную доставку. Воплощение SOA на уровне инфраструктуры.

graph TD
    subgraph "Системы"
        A[CRM]
        B[Биллинг]
        C[Склад]
        D[Интернет-магазин]
        E[ERP]
    end
    ESB((ESB))
    A <-->|"JMS/SOAP"| ESB
    B <-->|"JMS/XML"| ESB
    C <-->|"REST/JSON"| ESB
    D <-->|"REST"| ESB
    E <-->|"SOAP"| ESB

Функции шины: медиация (протоколы, XSLT, обогащение), маршрутизация, централизованная оркестровка длительных процессов, безопасность, транзакции, журналирование. Legacy-контур часто опирается на SOAP/JMS — детали протоколов в 03.05.02 Синхронные протоколы (REST, gRPC, GraphQL) и 10.01.05 Шаблон спецификации SOAP API.

Типичный enterprise-мотив — MDM (Master Data Management) и «золотая запись»: шина нормализует справочники (клиент, продукт) для множества потребителей.

Плюсы: N соединений вместо N², слабая связанность через канонические форматы, централизованный мониторинг и политики безопасности, повторное использование маршрутов.

Минусы: высокая стоимость и сложность, риск единой точки отказа, превращение шины в монолит с бизнес-логикой, каскадное влияние изменений канонической модели, тяжёлый CI/CD (07.06 CICD и конвейеры — влияние на требования).

Когда уместно: десятки legacy-систем, сложная оркестровка с гарантией выполнения, жёсткий централизованный аудит (финансы, госсектор), устоявшаяся SOA-культура. Примеры платформ: MuleSoft Anypoint, IBM Integration Bus, Apache Camel, WSO2 — без превращения статьи в каталог вендоров.

2.4. API-led Connectivity

API-led — не замена ESB, а модель слоёв API, популяризированная MuleSoft и описанная в ряде enterprise-фреймворков:

  1. System API — оборачивают конкретные системы (ERP, CRM, БД), скрывая legacy (BAPI/IDoc → REST).
  2. Process API — сквозная бизнес-логика: оркестрация вызовов System API, агрегация, компенсации.
  3. Experience API — адаптация под канал (web, mobile, партнёр).
graph TD
    subgraph "Каналы"
        WA[Web]
        MA[Mobile]
        PA[Партнёр]
    end
    GW[API Gateway]
    subgraph "Experience APIs"
        EX1[Experience API Web]
        EX2[Experience API Mobile]
        EX3[Experience API Partner]
    end
    subgraph "Process APIs"
        P1[Process API: заказ]
        P2[Process API: клиент]
    end
    subgraph "System APIs"
        S1[Склад]
        S2[CRM]
        S3[Биллинг]
        S4[ERP]
    end
    WA --> GW
    MA --> GW
    PA --> GW
    GW --> EX1
    GW --> EX2
    GW --> EX3
    EX1 --> P1
    EX2 --> P1
    EX3 --> P2
    P1 --> S1
    P1 --> S3
    P2 --> S2
    P2 --> S4

Enterprise API Gateway — обязательный элемент ландшафта API-led для внутренних и внешних каналов: аутентификация, throttling, маршрутизация к Experience/Process API (03.06.03 Rate Limiting — управление пропускной способностью). Не путайте его с партнёрским/B2B-шлюзом (EDI, AS2, отдельный perimeter для контрагентов): в ADR явно указывайте, один продукт закрывает оба контура или это разные шлюзы (internal vs external).

Process API может реализовываться ESB, BPM, оркестратором или хореографией через события — выбор фиксируется отдельно (03.05.06 Event-Driven Architecture, 03.06.01 Архитектурные паттерны распределённых систем).

Плюсы: изоляция слоёв, повторное использование System API, независимое версионирование, API как продукт с документацией (03.05.03 Спецификации контрактов (OpenAPI, AsyncAPI, Protobuf)).

Минусы: много распределённых компонентов (шлюз, реестр, mesh), Saga и идемпотентность для консистентности (03.05.04 Асинхронное взаимодействие (очереди, Kafka, Events)), накладные сетевые задержки, потребность в contract tests, ADR и зрелом CI/CD (05.04 DevOps и непрерывная поставка — влияние на анализ).

Когда уместно: цифровая трансформация, омниканальность, API-first, постепенная модернизация legacy.

2.5. Сравнительная таблица

КритерийТочка-точкаHub-and-spoke *ESBAPI-led
СвязанностьЖёсткаяСредняя: звезда без канонической моделиСлабая через шинуСлабая через контракты API
Сложность управленияНизкая на старте, экспоненциальный ростНизкая–средняя; нет полноценной медиацииЦентрализованная, высокая сложность платформыРаспределённая, много API и инфраструктуры
Гибкость измененийКаскадные правкиСредняяСредняя: изменения шины затрагивают многихВысокая: изоляция слоёв
Batch / файловый обменТипичный сценарий (FTP, выгрузки)Центральный drop-zone / очередьЦентрализованная маршрутизация файловЧерез System API или отдельные адаптеры
Повторное использованиеМинимальноеМинимальноеМаршруты, трансформацииSystem API как блоки
Стоимость **Минимальная для малого контураНизкаяВысокая (лицензии, экспертиза)Зависит от масштаба: enterprise-шлюз + mesh могут быть дороже «лёгкого» ESB
ОтказоустойчивостьКаскадные отказы; нет единой политики retryРиск SPOF брокера без политик шиныЦентрализованная обработка ошибок; SPOF шиныРаспределённая; нужны паттерны устойчивости (03.06.01 Архитектурные паттерны распределённых систем)
Типовой сценарийПрототип, 2–3 системы, batch P2PBatch через общий брокер, переход к ESBLegacy enterprise, MDM, оркестровкаОмниканальная платформа, API-first

* Hub-and-spoke — не четвёртый «вид» из заголовка статьи, а упрощённая звезда между P2P и ESB (см. раздел 2.2).

** Стоимость — эвристика; сравнивайте TCO конкретного ландшафта, а не абстрактные метки «средняя/высокая».

3. Как применяется в работе аналитика

3.1. С чего начать

  1. Постройте контекстную диаграмму (03.01.02 Моделирование контекста системы (Context Diagram)) и интеграционную матрицу (система A → B, паттерн, протокол, режим sync/batch, SLA). Связь строк матрицы с бизнес- и функциональными требованиями при необходимости ведите через 10.01.15 Шаблон матрицы трассировки — это уже трассировка требований, а не замена интеграционной матрицы.
  2. Для каждого обмена зафиксируйте: цель (данные / функция / канал), режим (real-time vs batch), объём, критичность, RPO/RTO на стыке, регуляторику. Жёсткий end-to-end latency при множестве legacy-систем — сигнал осторожности с длинными P2P-цепочками и синхронным API-led без async; чаще уместны ESB/Process API или асинхронный обмен.
  3. Оцените организационный контекст: закон Конвея — централизованная шина опирается на интеграционную команду; API-led и доменные API — на автономные продуктовые команды (03.06.02 Основы Domain-Driven Design). Зафиксируйте ownership интерфейсов: кто меняет контракт System API, кто — маршрут на шине, кто согласует breaking change — иначе ADR останется чисто техническим (09.06 Ведение переговоров с техническими командами).

Вопросы на discovery-сессии (02.02.01 Интервьюирование и анкетирование, 02.02.02 Воркшопы, фасилитация и совместные сессии):

  • Сколько систем участвует в обмене и как часто добавляются новые стыки?
  • Какой режим критичен: real-time, near-real-time или batch по расписанию?
  • Какие SLA/RPO/RTO и регуляторные ограничения действуют на каждом стыке?
  • Есть ли уже ESB, iPaaS или корпоративный API Gateway — и кто их эксплуатирует?
  • Как часто меняются контракты и кто владелец каждого слоя API (System / Process / Experience)?

3.2. Чеклист выбора паттерна

Если…Склоняйтесь к…
≤ 3 системы, ограниченный бюджет, срок «вчера»P2P (с явным техдолгом и планом миграции)
Преобладает batch/FTP, редкие измененияP2P или hub-and-spoke; ESB/iPaaS при централизованном контроле
Жёсткий end-to-end latency + много legacyESB/Process API или async; осторожно с цепочками P2P и синхронным API-led
Десятки legacy, разные протоколы, MDM, строгий аудитESB / iPaaS (тот же класс решения «централизованная медиация», другой деплой)
Уже есть ESB и компетенцииРасширение шины; бизнес-логику — не в шину сверх медиации
API-first, много каналов, частые релизыAPI-led + enterprise Gateway
Legacy + новые цифровые сервисыГибрид: ESB/iPaaS для legacy-блоков, API-led для новых зон — границу зафиксируйте в ADR (03.01.03 Декомпозиция системы на подсистемы и модули)

3.3. Что фиксировать в артефактах

3.4. Современный контекст (не четвёртый «вид»)

iPaaS (Boomi, Azure Logic Apps) для аналитика — тот же ADR-выбор, что и ESB: централизованная медиация, но в облачном деплое; в чеклисте «ESB / iPaaS» — один класс решений, а не четвёртый паттерн наряду с API-led.

Service mesh и event-driven подходы дополняют классическую тройку, но не образуют отдельный «вид» интеграции: mesh — инфраструктурный слой для микросервисов; EDA — стиль взаимодействия (03.05.06 Event-Driven Architecture). При описании ландшафта указывайте, какой слой закрывает каждая технология, чтобы не смешивать топологию, middleware и стиль обмена.

4. Типовые ошибки и ограничения

  • Смешение API-led и ESB — объявление API-led «лёгкой заменой шины» при использовании той же интеграционной платформы для Process API и маршрутизации.
  • Hub-and-spoke как «четвёртый вид» — упрощённая звезда не равна ESB и не входит в тройку заголовка; фиксируйте её как переходный или осознанный минимальный вариант централизации.
  • Путаница целей и паттернов — вывод пользовательской интеграции (портал) как отдельного «вида» наряду с P2P/ESB/API-led.
  • iPaaS как отдельный вид — облачный middleware решает ту же задачу медиации, что ESB; различайте деплой и вендора, а не топологию.
  • Игнорирование batch — на схеме есть FTP/CSV, в требованиях и таблице сравнения — только REST.
  • Оркестрация без владельца — не зафиксировано, кто реализует Process API: ESB, BPM, оркестратор, хореография событий.
  • P2P без техдолга — «временная» спагетти без плана и без единых политик отказоустойчивости.
  • ESB-монолит — вся бизнес-логика в шине; изменения становятся узким местом всей организации.
  • API-led без Gateway и governance — десятки «сырых» API без реестра, версионирования и безопасности; смешение enterprise Gateway и B2B-шлюза в одной строке ADR.
  • Универсальная таблица стоимости — enterprise API-ландшафт может быть дороже малого ESB; всегда привязывайте оценку к масштабу.
  • B2B-слепое пятно — в ERP/retail часто нужны EDI/AS2 и партнёрские шлюзы; если контекст B2B, явно отметьте это в интеграционной матрице (детали протоколов — 03.05.02 Синхронные протоколы (REST, gRPC, GraphQL) и смежные заметки).

Связи с другими разделами базы

Источники и дополнительные материалы

Книги и стандарты

  • Hohpe, G., Woolf, B. (2003). Enterprise Integration Patterns: Designing, Building, and Deploying Messaging Solutions. Addison-Wesley. — https://www.enterpriseintegrationpatterns.com/ (hub-and-spoke, message broker, медиация — нейтральная база паттернов)
  • Newman, S. (2015). Building Microservices: Designing Fine-Grained Systems. O'Reilly.
  • The Open Group. TOGAF Standard — Integration Architecture, стили интеграции и архитектурные решения на уровне предприятия.
  • ISO/IEC/IEEE 42010:2011 — описание архитектурных видов и решений.

Статьи и материалы

Курсы и документация

  • Enterprise Integration Fundamentals (MuleSoft Training)
  • Software Architecture: Integration Patterns (O'Reilly Learning)
  • Документация Apache Camel, WSO2 — примеры реализации ESB-паттернов.