Да все бы так аргументировать

Попробую

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

Для развязки потребителя с поставщиками можно мидлвейр и использовать

Да

Иными словами, при взаимодействии нужно адаптироваться к контактам (API). Поскольку API вызывает (грубо) потребитель, он осведомлён о контракте постащика, естественным образом зависит от него, то адаптер (с трансформацией) должен быть на стороне потребителя.

Это зависит от того, есть ли "естественная", то есть явная связь между поставщиком и потребителем. Обычно такая связь есть. Но, согласен, тут многое зависит от стиля взаимодействия

Даже если потребитель один, то я бы всё-равно взаимодействие вынес бы в некий интеграционный шлюз

Но вообще, когда умные люди учили меня SOA, они постоянно говорили - нужно избегать интеграции, там где это возможно.

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

Почему?

Стретегия, сейчас один, завтра нет. И всё-таки бизнес-функцие с интеграцией (инфраструктурой) разделять

Для простоты управления

И главное определения точки управления этим

Не вижу простоты.

Миддл уровень кто будет сопровождать/обновлять? Разница в ЖЦ мидла и потребителя может сказаться на TTM потребителя.

Кроме того, таким образом усложняется коммуникация между разработчиками, они обычно из разных команд.

Да, тут риск, я согласен, думал

Управлять завимостью нужно там, где она существует в явном виде. Паттерн Information Expert

А тут она не явная?

Иными сломи, потребитель при наличии зависимости, а она почти всегда присутствует, должен передать свою осведомлённость миддлу