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

Всё сказанное ниже в основном касается крупных ESB (типа IBM Integration Bus), на которые "нацеплены" большая часть ИС (информационных систем) предприятия.
Если же мы говорим о продукта типа Apache Kafka и RabbitMQ, использующихся в качестве КСШ, то с ними всё гораздо проще, кроме того, они часто задействованы в микросервисной и service-mesh архитектуре, а также в смешаной архитектуре.

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

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

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

1. ESB с высокой вероятностью становится единой точкой отказа (single point of failure, SPOF), сиречь, если рушится она, то рушится взаимодействие всех систем, которые "общаются" через неё.
2. ESB могут стать "узким горлышком" ещё в том смысле, что множество команд разработки других ваших систем будут вынуждены ждать выхода в ПРОМ доработок от команды ESB. Больше зависимостей --> больше общий TTM (time to market).
   Всё это может значительно усугубиться в ситуации, когда в вашей компании количество специалистов, "знающих Шину" — близко к нулю.
3. Обязательно д.б. выстроен процесс сохранения и актуализации артефактов проектирования, разработки, тестирования Шины и всех систем, работающих с оной. Нужны Архитекторы, и они должны быть "пишущие".
4. Заклинаю, НЕ надо совать в Шину бизнес-логику, проблем потом не оберётесь. Использовать Шину следует ТОЛЬКО как ТРАНСПОРТ.
   Да и вообще идея вставлять бизнес-логику в вендорные решения и фреймворки — нарушение принципов DDD и заключение вашего предприятия в т.н. vendor-lock.
5. На Шину со множеством адаптеров обязательно нужны автотесты, руками регресс десятков-сотен кейсов адаптеров не покроется, особенно если необходимость в регрессе возникает раз в несколько дней или чаще, ведь на Шине с большой связанностью постоянно будет что-то меняться. Вопрос: стоит ли "вешать" разработку и тестирование на вендора?
   Автотесты требуют всегда актуальных артефактов п.4.

• Облачные решения:
  • 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://rabbitmq.com/, очень популярно
  • IBM Integration Bus https://ibm.com/docs/en/integration-bus/
  • Oracle Service Bus https://oracle.com/middleware/technologies/service-bus.html
  • TIBCO ActiveMatrix Service Bus https://docs.tibco.com/products/tibco-activematrix-service-bus-latest
  • MuleSoft MuleESB https://mulesoft.com/platform/soa/mule-esb-open-source-esb
  • Microsoft BizTalk Server 2016 https://microsoft.com/ru-ru/evalcenter/evaluate-biztalk-server-2016
  • YDB Яндекса https://ydb.tech/docs/en/concepts/, является одновременно и СУБД и шиной, похожей на Apache Kafka, предназначено для высоконагруженных решений.
    Статья: Как Яндекс создал свою шину данных, чтобы передавать сотни гигабайт в секунду

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 (как умеет Apache Kafka)
3. Интеграция данных (ETL, ...)
4. Средства управления сервисами (circuit breaker)