Enterprise Service Bus (ESB) / Корпоративная сервисная шина (КСШ) = ПО, обеспечивающее централизованный и унифицированный обмен сообщениями между различными ИС предприятия. Подробнее в wikipedia.
Если в "дошинную" эпоху общепринятой концепцией была интеграция различных систем друг с другом напрямую, т.н. соединение "точка-точка", то с появлением шины — она становится главным транспортным узлом в интеграционной архитектуре предприятия, в определённом смысле объединяя в себе все API предприятия:

скачать схему в формате diagrams.net (бывший draw.io)

Общая концепция КСШ:

скачать схему в формате diagrams.net (бывший draw.io)

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

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

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

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

• Облачные решения:
  • Azure Service Bus https://azure.microsoft.com/ru-ru/services/service-bus
  • Amazon Simple Queue Service https://aws.amazon.com/ru/sqs/
• On-premise решения:
  • Apache Kafka https://kafka.apache.org/, очень популярно
  • RabbitMQ https://www.rabbitmq.com/, очень популярно
  • IBM Integration Bus https://www.ibm.com/docs/en/integration-bus/
  • Oracle Service Bus https://www.oracle.com/middleware/technologies/service-bus.html
  • TIBCO ActiveMatrix Service Bus https://docs.tibco.com/products/tibco-activematrix-service-bus-latest
  • MuleSoft MuleESB https://www.mulesoft.com/platform/soa/mule-esb-open-source-esb
  • Microsoft BizTalk Server 2016 https://www.microsoft.com/ru-ru/evalcenter/evaluate-biztalk-server-2016

1. Асинхронные развязки при обработке команд
2. Брокер очереди сообщений (Message Queue, MQ), маршрутизация сообщений в соответствии с заданными правилами, настройка приоритетов обработки
3. Преобразование сообщений: обогащение сообщений данными, фильтрация по правилам, трансформация протоколов (нормализация) и форматов (XML, JSON, CSV, ...)
4. Гарантированная доставка сообщений: контроль над доставкой, переотправка при необходимости
5. Протоколирование (логирование) бизнес-операций
6. (в современных 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)