В любом случае, важность решения определяется стоимостью его изменения. Если разница в стоимости несущественная (а Published Language тоже имеет свою стоимость, так как велика осведомленность о нем), то решение не принципиально.

Во-втором случае Вам будет легче адаптироваться к изменениям публичного интерфейса поставщика данных, который вы, как я понял, не контролируете. А в первом случае вам будет легче эволюционировать собственную систему, так как сервисы не связаны единым форматом данных Published Language.

Слушай, круто написал.
У меня идёт примерно 40 неделя проекта интеграции, и я тут две недели назад удивился, что под интеграцией подразумевается "не хочу знать, как там за пределами product scope". Другими словами, "интеграция" как способ уберечь себя от процессов снаружи.

Каждый проект интеграции по моему таков, всегда в рамках схемы "BlackBox'ы" важны только входные данные и исходные. Не более. А их определяет архитектура приложения опираясь на архитектуру данных в целом.

+

Ну по крайней мере я с таким только и сталкивался, и думаю это оптимально по скорости. При отсуствии ESB.

*скорость реализации проекта, с продуктом удовлетворяющим требованиям

Тут нужно различать взаимодействие и интеграцию. Эти понятия часто "слипаются", порождая киборгов.

Я про интеграцию. Взаимодействия в моей работе мало, почти нет. Между системами. А то что есть реализованно на приемлемом уровне

Маловероятно по этому, не используется, не связаны, сейчас, и не планируется, никогда. Но при развитии ландшафта такой момент может наступить, например при вводе на замену легаси какой-нибудь системы. Кейс можно не рассматривать.

В моем случая вопрос где разместить этот транслятор, а не что делать с форматами

Давай про реальность поговорим: возьмём набор интеграционных контрактов на передачу-приём-обработку 5-10 XML/JSON и feedback по факту отправки + по валидности данных.

В процессе выясняется, что контракты были умозрительно правильно выполнены, а фактические реалии другие. Пересогласование контрактов.
Потом выясняется, что нужно обогатить данными, так как вторая линия поддержки  не вывезет общение только в тех.терминах (нужны данные в бизнес-терминах).
Пересогласование контрактов.
Потом оказывается, что нужны кросс-проверки в middleware интеграции и обогащённая обратная связь.
Пересогласование контрактов.

Давайте поговорим про пересогласование контрактов

"в идеале, каждый строительный блок решения должен быть чёрным ящиком с контрактом, тогда он будет независимым и автономным"

Положение транслятора достаточно определено. Насколько я вас понял, то вопрос стоит Translator vs Message Mapper https://www.enterpriseintegrationpatterns.com/patterns/messaging/MessagingMapper.html
В любом случае, если такой вопрос возник, то, по всей вероятности, вы не получили представления об Anti-Corruption Layer, так как он транслятор не использует.

@emacsway
Нет же, вот вопрос, вы видимо не туда посмотрели

Или я так выразился неудачно

Другими словами, давайте поговорим про ложь.
Контракт - это способ принятия, что и ты лжёшь, и я лгу - но мы в силах будем с этим что-то сделать. Нам важно то общее, ради чего вообще мы тут с тобой собрались.

Так оно и есть, контракт это согласованность, уровень лжи контракта не важен. Если он согласован с двух сторон.

Обогащение это дургая функция, модуль, это уже не котракт, это уже модуль аналитики, обогащения BI по сути. Если мы говорим про обогащение, а не расширения набора сырых данных.

Кросс проверки, так же вопрос практик, по сути это уже уровень не архитектуры ландшавта, а соглашения и практики внутрии организации к командам разработки