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

Карта памяти немного устарела уже.

@GKruglov а можете в двух словах написать различие интеграции и взаимодействия?

В двух словах различие описано выше

Вот согласен.

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

https://habr.com/ru/post/516176/

Сейчас читаю книгу https://www.oreilly.com/library/view/fundamentals-of-software/9781492043447/. Книга нравится, но хотелось бы побольше разбора примеров архитектур конкретных продуктов, побольше примеров. Может подскажите, что почитать ? То есть описывается архитектурный стиль, а потом пример его применения на практике с конкретными продуктами. Например, event-driven architecture style реализуется с помощью Kafka, ... вот так и так

Всё же попробую сформулировать ещё раз. Но буду упрощать, копаться в потрохах SOA и закидывать ссылками и их анализом уже не хочется.

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

Взаимодействие может быть выполнено в двух стилях: оркестровки и хореографии.

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

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

Геннадий, спасибо!

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

Надеюсь, удалось передать разницу)

Для себя я примерно так увидел. Если  ИС1 использует публичное API ИС2 - это взаимодействие. Если ИС2 разрабатывает какой-то шлюз или адаптер для ИС1 - это интеграция.

>Взаимодействие может быть выполнено в двух стилях: оркестровки и хореографии.
А можете, пожалуйста, немного расшифровать?

Не вполне точно. ИС2 должно иметь адаптер к API ИС 1. При этом ИС 2 осведомлено об API ИС1 и имеет возможность к нему адаптироваться в случае изменения (изменить адаптер).

А вот если ИС2 разрабатывает сторонний разработчик, то есть возможности адаптации у ИС2 нет, или нарушены коммуникации, то уже нужна интеграция.

Так же интеграция нужна если у ИС1 нет контракта/API. Тогда приходится, например, реплицировать базу ИС1, сверху делать API или вообще реплицировать сразу данные из базы ИС1 в базу ИС2 (плохой сценарий)

надо  тут помозговать ) Я долгое время считал, что взаимодействие и интеграция это синонимы. Потом как-то заказчик вскольз упомянул, что это о разном.
Еще раз спасибо!

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

👌

Пожалуйста без обид, это легко гуглится.