блин, хорошо если у Вас за ESB одна команда отвечает :) .
Хотя вообще ее задачи ведь интеграционные - нужно ли им разбираться в отдельных доменах - я не очень уверен

может у нас просто ESB для разных целей служат :)

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

классический цикл развития ESB
- выбрали вендора, купили продукт, отдали технической команде
- все приходят и хотят сервис, в котором есть немножко бизнес-логики
- ESB становится местом, где сосредоточена кросс-доменная логика - сам по себе непростой вопрос, да еще и по куче доменов
- команда ESB (изначально техническая) охреневает и не справляется / выстраивает конвеер и делает хорошо, но очередь длинная
- надо сделать новую ESB для ABS/CRM/you-name-it
...
- имеем 2 ESB, которые еще и надо интегрировать

а зачем бизнес-логику на ESB? мы точно про разные ESB

Простая задача - тут как раз на днях всплыла.
Рассылка нотификаций пользователям. В разных странах разная цена SMS, PUSH, у компании договора с разными операторами и т.д. + у разных решений разная стоимость. Есть отдельная команда которая вообще занимается анализом в этой области. Отдельные команды по некоторым странам делают реализацию для страны - т.к. есть троебования о хранении данных (регулируется законодательно - к примеру вы можете держать данные используемые для страны только в самой стране). ESB выставляет единую точку и единый интерфейс для messaging. Все приложения в рамках компании используют (обязаны) только его.
Задача ESB команды - настроить роутинг по каким-то входным параметрам - обработкой непостредственно данных занимаются уже конкретные системы. При этом если нужно их периодически меняют.

как пример - на ESB никакой логики - в общем - роутинг + единый интерфейс для всех

это хорошо, когда действительно так

ну я ESB для себя определяю именно в таком ключе - транспорт + единые интерфейсы для интеграции  + транформация данных + роутинг, может быть ещё что-то, но за пределами бизнес-логики

Кроссдоменной логики не бывает. Если она есть, значит неправильно выделены домены

Может быть "временно непристроенная" логика, но ей тоже не место в интеграционном решении

ну мы же про факт, а не про идеал

ESB это шина уровня предприятия - не уровня ABS/CRM - хотя у нас их 2 - шина внутри страны и еще одна для всех кто снаружи

Нет, это факт. Кроссдоменной логики не бывает. Может быть логика, которую нужно быстро реализовать без проектирования (вне одного из доменов), то есть костыли.

Другой вопрос в том, что такие костыли автоматом "идут" в ESB (жировую прослойку)

да, и часто кандидатом на это становится ESB

Именно. А потом они там так и остаются

но это не прямая проблема паттерна ESB
это тот самый технических долг, который потом всё хоронит

может я ошибаюсь - но у меня стойкое убеждение что Вы называете ESB то что по сути ESB не является. :)

мне прилетала похожая с виду задачка, только для отправки писем из банка разными компаниями
только там их API на столько непохожи, что сама их унификация требует отдельного сервиса со своей БД
даже с СМС подозреваю есть некоторые подводные камни

Почитайте пожалуйста чат выше по ключевому слову ESB. Не хочется персонально Вас убеждать в обратном

не должно называться ESB, согласен, но по факту такое случается (в крупных компаниях)
И то, что это случается нередко, показывает, что для этого есть причины, сложности, которые лежат в области управления, а не технической.