Middleware нужен не для того, чтобы «все интеграции шли через одно место». Он нужен тогда, когда общие задачи обмена уже нерационально решать в каждой системе отдельно

Интеграционный слой может:

маршрутизировать;

преобразовывать;

доставлять;

контролировать;

защищать.

Но если именно в нём начинают жить:

ценообразование;

правила клиента;

складская логика;

согласование договора;

расчёт себестоимости —

границы систем снова размываются.

AMPE оставляет бизнес-правила у их владельцев.

ESB может выполнять сложную маршрутизацию и преобразование.

iPaaS — давать управляемую платформу интеграций в cloud/hybrid-среде.

API Gateway — управлять API-трафиком и политиками.

Message broker — доставлять сообщения и события.

Они могут сосуществовать.

Но не нужно покупать каждый слой только потому, что он существует как категория.

Пять систем используют один формат клиента.

Несколько приложений требуют одинакового authentication flow.

Все ошибки нужно мониторить централизованно.

Партнёр присылает XML, внутренние системы работают JSON.

Тогда общий слой снижает дублирование.

Если каждая пара систем создаёт собственный mapping, количество преобразований растёт.

Canonical model уменьшает число вариантов.

Но попытка создать «идеальную модель всего предприятия» часто заканчивается слишком тяжёлым общим контрактом.

AMPE использует канонизацию локально там, где она действительно снижает связность.

Сообщение пришло.

По какому правилу ушло в систему B?

Почему не в C?

Какая версия маршрута действовала?

Без этой информации middleware становится чёрным ящиком.

AMPE делает routing observable и versioned.

Orchestrator явно знает последовательность шагов.

Choreography строится на реакциях участников на события.

Для сложного процесса с компенсациями orchestrator может быть сильнее.

Для независимых реакций — события.

Middleware не должен автоматически становиться orchestrator каждого процесса.

`customer_id` → `client_code` — простой случай.

Но часто требуется:

справочник;

единица измерения;

нормализация адреса;

разные форматы даты;

объединение объектов;

вычисляемое поле;

разная семантика статусов.

AMPE хранит mapping как управляемую часть контракта.

Middleware может автоматически повторить временный timeout.

Но не должен бесконечно пытаться провести документ, который нарушает бизнес-правило.

Техническая ошибка и бизнес-отказ получают разные маршруты.

Значит, для него нужны:

HA;

capacity;

observability;

backup/config recovery;

security;

change management;

DR.

Централизация интеграций одновременно централизует часть риска.

Low-code mapping и готовые connectors ускоряют старт.

Но важно понимать:

как экспортируются flows;

как тестируются;

как версионируются;

можно ли автоматизировать deploy;

что произойдёт при смене платформы.

AMPE смотрит на жизненный цикл, а не только на скорость первого подключения.

Системы сохраняют ownership бизнес-логики.

Middleware берёт на себя повторяющиеся интеграционные функции.

Contracts описывают вход и выход.

Routing и transformation управляются централизованно.

Monitoring показывает путь обмена.

Ошибки получают контролируемую обработку.

Так integration layer уменьшает хаос связей, не создавая новый монолит.

Mapping меньше дублируется.

Интеграции получают общую наблюдаемость.

Security policies становятся единообразнее.

Legacy и современные протоколы можно связать через адаптеры.

Изменения легче контролировать.

И главное — ландшафт перестаёт быть сетью случайных point-to-point соединений, не превращаясь при этом в один гигантский интеграционный узел.