Ок, поищу, спасибо.

orchestration vs choreography

страница 24

Я про к этому

Что нужно учесть. При реализации сценария взаимодействия/бизнес-процесса с помощью оркестрации, адаптеры должны быть на стороне оркестратора, поскольку оркестратор по сути является потребителем сервисов, которые он "вызывает" при исполнении сценария.

То есть оркестратор зависит от контрактов композицию которых он выполняет. Адаптация (разработка адаптера) всегда выполняется в зависимом компоненте.

С хореографией проще - это по своей природе непосредственное взаимодействие.

Ещё кто-то сомневается? Хореография мертворожденный вид взаимодействия

Не соглашусь. Особенно если речь о высокогруженных решениях.

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

Ну да, не прав в категоричности, к сложным системам применимо

Напомню, в SOA допускался только один вид зависимости - от контракта.

В микросервисной архитектуре пока до этого не созрели. Или я что-то пропустил.

Я пока думаю про оркестрацию внутри агрегата и хореографию между.
т.е. оркестрация для взаимодействий, хореография для интеграции.

Хореография сильно сложнее в поддержке.

Как и в проработке

И гарантирует сильную связанность

Как раз наоборот. Кидаешь событие в очередь и все.

Думаю с графа и тоже инверсия в микросервисах получается. Если в классическом BPM узлы это действия, а ребра изменение состояния. То в mcs узлы это состояния, а на ребрах действие, что напоминает скорее паттерн state machine. Но ещё интереснее в высокоскоростных highload системах с асинхронным event source исполнением. Там появляются практически 'квантовый эффекты' :) объект может пребывать сразу в нескольких состояниях, поскольку время исполнения действия того же порядка что и фиксация супер позиции. В итоге сложным становится не Определение какое действие выполнить дальше по процессу, а понять где я собственно говоря нахожусь.. Это отлично понимают и фанаты CQRS и адепты SAGA

Так что топологии графов, и пользующихся в MCS ещё ждёт осмысления, своих Эйлеров и Марковых...

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

В одном из проектов мы даже нарабатывали навык "спрямления" процессов в ацикличные графы.

Совершенно верно, был даже такой мем на эту тему (кстати, в твите автора CQRS): https://mobile.twitter.com/gregyoung/status/1101642600342265857

Согласен что в MCS переборщили со слоями абстракций, пытаясь управлять спеками REST, API gateway, data layer, docker контейнерами и пр другими библиотеками, которые в свою очередь дают ещё абстракций и зависимостей, провоцируя холивары фанатов k8s и openshift, kafka и rabbit mq. Жду пока там 'переизобретут' монолит и структурные программирование