Enterprise Service Bus (ESB) / Корпоративная сервисная шина (КСШ) = ПО, обеспечивающее централизованный и унифицированный обмен сообщениями между различными ИС предприятия. Подробнее в wikipedia

Являет собой эволюционный виток архитектурной мысли в рамках сервисно-ориентированной архитектуры в "домикросервисную эпоху". Хорошо подходит для средних размеров предприятий с относительно небольшим количеством ИС (десятки).

Оглянувшись на свой и чужой опыт, можно извлечь несколько уроков использования КСШ:

1. Заклинаю, не надо совать в Шину бизнес-логику, проблем потом не оберётесь. Использовать Шину следует только как транспорт.
   Да и вообще идея вставлять бизнес-логику в вендорные решения и фреймворки -- нарушение принципов DDD и заключение вашего предприятия в т.н. vendor-lock;
2. ESB могут стать "узким горлышком", когда множество команд других ИС ждёт доработок от команды ESB. Больше зависимостей --> больше общий TTM (time to market).
   Всё это может значительно усугубиться в ситуации, когда в вашей компании количество специалистов, знающих Шину -- стремится к нулю.
3. На Шину со множеством адаптеров обязательно нужны автотесты, руками регресс десятков-сотен кейсов адаптеров не покроется, особенно если необходимость в регрессе возникает раз в несколько дней или чаще, ведь на Шине с большой связанностью постоянно будет что-то меняться. Вопрос: стоит ли "вешать" разработку и тестирование на вендора?
   Автотесты требуют всегда актуальных артефактов п.4;
4. Должен быть выстроен процесс сохранения и актуализации артефактов проектирования, разработки, тестирования Шины и всех ИС, работающих с Шиной. Нужны Архитекторы, и они должны быть "пишущие".

В основном это касается крупных ESB, на которые "нацеплены" большая часть ИС предприятия.
Если мы говорим о "небольших" шинах типа Kafka и RabbitMQ, то с ними всё гораздо проще, кроме того, они часто задействованы в микросервисной и service-mesh архитектуре, а также в смешаной архитектуре.

• Облачные решения:
  • Azure Service Bus
  • Amazon Simple Queue Service
• On-premise решения:
  • RabbitMQ, очень популярно
  • Kafka, очень популярно
  • IBM Integration Bus (IBM)
  • Oracle Service Bus (Oracle)
  • BizTalk (Microsoft)
  • ActiveMatrix Service Bus (TIBCO)
  • MuleESB (MuleSoft)
  • JBoss Fuse ESB (Red Hat)

1. Асинхронные развязки при обработке команд
2. Маршрутизация данных, брокер очереди сообщений (Message Queue, MQ)
3. Гарантированная доставка информационных сообщений
4. Преобразование: обогащение/фильтрация сообщений, преобразование протоколов (нормализация)
5. Синхронизация изменений
6. Протоколирование (логирование) Бизнес-операций
7. (в современных ESB) MFT = Managed file transfer

1. Добавляется ещё одна ИС, которую надо обслуживать
2. Потребуется закупать мощности для развёртывания и включения в текущие тестовые контуры ещё одной ИС
3. ESB может стать "узким горлышком", когда множество команд других ИС ждёт доработок от команды ESB. Больше зависимостей --> больше общий TTM.
   Всё это усугубляется, если количество специалистов, знающих вашу Шину, стремится к нулю;

Что Шина НЕ даёт

1. Описание и прототипирование API (как умеет Swagger, Postman et cetera)
   Это может быть размещено в CoreAPI.
2. Stream processing (как умеет Kafka)
3. Интеграция данных (ETL, ...)
4. Средства управления сервисами (circuit breaker)