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

скачать схему в формате 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. Гарантированная доставка информационных сообщений
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)