Почему "единую"? Оркестраторов может быть много. Может быть по одному на бизнес-домен или на fitness-function или как-то еще.
На самом деле событийная модель точно так же требует централизованного управления "какие события бывают и как на них реагировать".

Только не работает оно. Ну не рисует аналитик качественный BFF из квадратиков в комунде. Так как не думает про отказы, повторы, скрипты отмен и прочие важные штуки. А если думает - то написать код ему будет быстрее, так как он и так уже программист.

Ну, у нас есть меш (свой), сейчас доделываем оркестратор (и это, кстати, совершенно независимые элементы).
И оркестратор, конечно, не request-response, а акторный.

работает, у нас в проде. около 10 систем уже имеют сервисы сгенерированные оркестратором/мешапером
(но много своих решений, включая окрестратор и системы мониторинга)

А если "через шину данных", то где бизнес-логика живет? Как ее поменять?
Вот у тебя обычный такой платеж, где надо дернуть 20 систем, из которых 10 вообще контрагентов. По сложной логике.
Где эта логика будет?

А аналитики у вас рисуют скрипты компенсации и поведения при сбое каждого из вызовов в оркестрации? И пишут скрипты для тестирования своих скриптов? И сами отлаживают баги на проде?

пишут небольшие скриптовые вставки в духе просто маппинга данных. а так много типовых "кубиков" с довольно простыми настройками
компенсации и прочие саги, пока живут в других местах, оркестраторы запущенны в оснвоном для bff и интеграционных задач.
функциональные тесты апишек помогают писать разрабы, но мы работаем чтобы это тоже автоматизировать по максимум и упросить

Если про маппинг - то это не про окрестратор, это про bff, там можно делать UI (хотя dsl подходит лучше).
Оркестратор все-таки больше про обеспечение целостности и нужных гарантий в сложном неконтролируемом окружении.  
И я плохо понимаю, как это может сделать аналитик, который не программист. И саги, кстати, обычно не помогают - так как обратные операции в самых интересных случаях не возможны.

И я не про тесты апишек, я про тесты сценариев. Включая производительность и поведение при сбоях.

не соглашусь, оркестратор - это очень абстракная концепция, по сути инструмент координации и упралвения чем либо. приминительно к задаче bff и мэшапу- это штука которая позволяет настроить, что как и откуда брать, куда и как выдавать. приминительно к процессам - это bpmn, который позовляет описать и настроить его шаги.

если сервисы stateless, то это не нужно. обычно задачи мэшапера это как раз stateless апишки

Вот для мэшапера (т.е. реализация обогащений, если я правильно понимаю) - да, там тесты разве что на производительность нужны (дабы не вылезло n+1 в неправильном месте).
Но это все реализации паттерна bff, это (мне) не так интересно, так как достаточно очевидно.

А вот оркестрация для сложных задач изменений данных - это уже менее очевидно.

- есть всего два вида организации взаимодействия между сервисами, оркестрация и хореография
- саги - это шаблон организации распределённой (бизнес) транзакции
- саги можно реализовать как на основе оркестрации, так и на основе хореографии
- для оркестрации нужен оркестратор
- оркестратор можно написать с нуля, а можно взять готовый
- часто удобно для оркестрации использовать bpm движки
- bpm движки имеют ограниченную производительность и отказоустойчивость
- мир не стоит на месте, распределённые и отказоустойчивые оркестраторы разрабатываются, например Zeebe
- нужно почитать Ричардса и понять, где он увидел проблему

Возможно Ричардс заблуждается

Кстати, а за что так любят саги? Там же и код ужасный и результат сложно гарантировать?

Ну сага это же паттерн

Угу. Но я плохо себе представляю, как этот паттерн красиво реализовать. И требование "компенсируемости" каждой операции - очень сильное.
И не понятно что делать при ошибках при проведении компенсации )

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

Я тоже не представляю)