Ну вот это и есть архитектура же. Если бы ты написал "проектирование" - то ок, но архитектура про "соглашения и практики внутри организации и ... + ..."

Перечитал. Вроде понял все правильно. Если за преобразование данных отвечает их конечный потребитель, то это - Anti-Corruption Layer (и Message Mapper). А если существует отдельный узел для преобразования данных и питания ими всех потребителей, то это - Published Language (и Message Translator).

Вопрос Anti-Corruption Layer vs Published Language хорошо описан в литературе по DDD. А вопрос Message Mapper vs Message Translator (при условии, что данные доставляются сообщениями, а не, например, File Transfer, Pub/Sub etc.) хорошо описан в EIP и в RMPwAM. Что-то добавить от себя здесь сложно.

Но я бы начал все-таки с причины появления этого вопроса. Когда сервисы дублируют данные, то это происходит обычно как Eventual Consistency реакция одного сервиса на изменения в другом сервисе с целью обеспечения автономности сервисов и владения данными. В вашем же случае я не совсем понимаю причины возникновения такой потребности, когда разные сервисы импортируют из внешнего источника одни и те же данные.

Все практики и соглашения? Код стайл это архитектура или? Я думаю что регламенты такого низкого уровня не нужны, иначе архитектура утонет.

Это примерно когда менеджер пытается контролировать часы в задачах. Ни к чему хорошему это не приводит.

Пока мы оставляем в умолчаниях домен архитектуры - всё плавает.
Есть оргдизайн, который является реализацией смысла "организационная архитектура" (Organizational architecture or organization design: the creation of roles, processes, and formal reporting relationships in an organization.).

Этот чат про "архитектуру ИТ-решений", с одной стороны. С другой - архитектура ИТ-решений не живёт в вакууме.

В основном, мы тут обсуждаем две темы:
1) "вариации проектирования решений для обеспечения операционной деятельности таких-то людей-отделов-служб-клиентов"
2) "как перейти из домена ИТ-архитектуры в домен архитектуры организации".

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

Почему взаимодействия нет? Это же ключевой вопрос.

Так точно )

На всякий случай, еще одна ссылка по теме: https://www.enterpriseintegrationpatterns.com/patterns/messaging/CanonicalDataModel.html

Но лучше смотреть в EIP, а не онлайн-каталог. В каталоге все слишком сухо и коротко.

На самом деле, есть альтернатива.

Поставщик публикует контракт, а потребители адаптируются.

Это единственный жизнеспособный вариант, когда потребителей много и/или их состав меняется.

Главное - потребители должны знать об изменениях заранее и иметь время на адаптацию. Обратная совместимость как минимум двух последних мажорных версий контракта, это одно из необходимых условий.

Совершенно верно. Именно поэтому, в одном из моих первых ответов, был отсыл к каталогу способов взаимодействия Bounded Contexts. Я упомянул только два способа, но их существенно больше, и все зависит от домена.

Mediation Framework содержит реализации почти всего каталога EIP.

Конкретный EIP нужно выбирать исходя из деталей задачи.

Именно. Иначе будет пробел в распределении обязанностей, то есть пробел в архитектурной работе.

Обязанность с высокой вероятностью "уедет" в уровень интеграции.

Можно глупый вопрос. Зачем предприятию постороение EA и ISA? Т.е. зачем мне выделять эти компетенции. Не более трех утверждений. Пример: Зачем мне EA и ISA умного города? Ответ: Создание комфортной (экологичной и безопасной), гибкой к изменениям среды обитания.

1) Чтобы смочь отделять знаки от значений от смыслов

2) отделять нужно чтобы уметь собирать и передавать определённые смыслы, которые отражают такие-то объекты-силы-феномены, и выражаются (называются) таким=то знаком

3) собирать и передавать нужно для того, чтобы en arche имело живой, гибкий, многовариантный вид.
Это обеспечивает устойчивость в управлении.

Ага?

Наконец-то кто-то решил создать единый словарик терминов в Российском IT:

https://cdto.wiki/Категория:Тезаурус

Вотпрос в тексте. Повторю "Зачем мне развивать компетенции, репозитории и другое EA и ISA на предприятии?" Типичный главный вопрос прежде чем продавать необходимость ЕА которого нет на предприятии.