Size: a a a

Архитектура ИТ-решений

2020 August 25

I

Ivan in Архитектура ИТ-решений
Ivan
В вашем случае вопрос звучит как Anti-Corruption Layer vs Published Language. Откройте справочник по способам взаимодействия Bounded Contexts, и выберете то, что вам больше подходит. Если больше подходит последнее, то, тогда добавьте https://www.enterpriseintegrationpatterns.com/patterns/messaging/MessageTranslator.html (можете от Camel https://camel.apache.org/components/latest/eips/message-translator.html )
В любом случае, важность решения определяется стоимостью его изменения. Если разница в стоимости несущественная (а Published Language тоже имеет свою стоимость, так как велика осведомленность о нем), то решение не принципиально.
источник

I

Ivan in Архитектура ИТ-решений
Ivan
В вашем случае вопрос звучит как Anti-Corruption Layer vs Published Language. Откройте справочник по способам взаимодействия Bounded Contexts, и выберете то, что вам больше подходит. Если больше подходит последнее, то, тогда добавьте https://www.enterpriseintegrationpatterns.com/patterns/messaging/MessageTranslator.html (можете от Camel https://camel.apache.org/components/latest/eips/message-translator.html )
Во-втором случае Вам будет легче адаптироваться к изменениям публичного интерфейса поставщика данных, который вы, как я понял, не контролируете. А в первом случае вам будет легче эволюционировать собственную систему, так как сервисы не связаны единым форматом данных Published Language.
источник

EI

Eugene Istomin in Архитектура ИТ-решений
Gennadiy Kruglov
Вот и нет. В реальной жизни, то есть де-факто, ESB становится суррогатом взаимодействия, то есть взамодействия через интеграцию, потому что непросредственное взамодействие невозможно из-за разрыва в коммуникациях или нежелания/неумения выполнять дизайн (лень/некомпетентность)
Слушай, круто написал.
У меня идёт примерно 40 неделя проекта интеграции, и я тут две недели назад удивился, что под интеграцией подразумевается "не хочу знать, как там за пределами product scope". Другими словами, "интеграция" как способ уберечь себя от процессов снаружи.
источник

F

Fagor in Архитектура ИТ-решений
Eugene Istomin
Слушай, круто написал.
У меня идёт примерно 40 неделя проекта интеграции, и я тут две недели назад удивился, что под интеграцией подразумевается "не хочу знать, как там за пределами product scope". Другими словами, "интеграция" как способ уберечь себя от процессов снаружи.
Каждый проект интеграции по моему таков, всегда в рамках схемы "BlackBox'ы" важны только входные данные и исходные. Не более. А их определяет архитектура приложения опираясь на архитектуру данных в целом.
источник

EI

Eugene Istomin in Архитектура ИТ-решений
Gennadiy Kruglov
- Нужно различать взамодействие и интеграцию
- Если речь идёт о взаимодействии, то потребители должны адаптироваться к поставщику, то есть трансформация должна выполняться в адаптерах потребителей
- Если речь идёт об интеграции (минимум двух компонентов/сервисов/систем), то трансформация должны выполняться в мидле/посреднике
+
источник

F

Fagor in Архитектура ИТ-решений
Ну по крайней мере я с таким только и сталкивался, и думаю это оптимально по скорости. При отсуствии ESB.
источник

F

Fagor in Архитектура ИТ-решений
*скорость реализации проекта, с продуктом удовлетворяющим требованиям
источник

EI

Eugene Istomin in Архитектура ИТ-решений
Fagor
Каждый проект интеграции по моему таков, всегда в рамках схемы "BlackBox'ы" важны только входные данные и исходные. Не более. А их определяет архитектура приложения опираясь на архитектуру данных в целом.
Тут нужно различать взаимодействие и интеграцию. Эти понятия часто "слипаются", порождая киборгов.
источник

F

Fagor in Архитектура ИТ-решений
Я про интеграцию. Взаимодействия в моей работе мало, почти нет. Между системами. А то что есть реализованно на приемлемом уровне
источник

VU

Vitaly U in Архитектура ИТ-решений
Ivan
А, интересно, почему одни и те же данные используются в разных сервисах? Какая причина? И еще интересно, почему несколько сервисов связаны одним и тем же форматом данных (т.е. дублируют его)?
Маловероятно по этому, не используется, не связаны, сейчас, и не планируется, никогда. Но при развитии ландшафта такой момент может наступить, например при вводе на замену легаси какой-нибудь системы. Кейс можно не рассматривать.
источник

VU

Vitaly U in Архитектура ИТ-решений
Ivan
В вашем случае вопрос звучит как Anti-Corruption Layer vs Published Language. Откройте справочник по способам взаимодействия Bounded Contexts, и выберете то, что вам больше подходит. Если больше подходит последнее, то, тогда добавьте https://www.enterpriseintegrationpatterns.com/patterns/messaging/MessageTranslator.html (можете от Camel https://camel.apache.org/components/latest/eips/message-translator.html )
В моем случая вопрос где разместить этот транслятор, а не что делать с форматами
источник

EI

Eugene Istomin in Архитектура ИТ-решений
Fagor
Я про интеграцию. Взаимодействия в моей работе мало, почти нет. Между системами. А то что есть реализованно на приемлемом уровне
Давай про реальность поговорим: возьмём набор интеграционных контрактов на передачу-приём-обработку 5-10 XML/JSON и feedback по факту отправки + по валидности данных.

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

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

EI

Eugene Istomin in Архитектура ИТ-решений
Gennadiy Kruglov
- в идеале, каждый строительный блок решения должен быть чёрным ящиком с контрактом, тогда он будет независимым и автономным
- при взаимодействии трудно представить кейс, когда поставщик зависит от потребителя, значит потребитель должен быть адаптирован к поставщику
- при интеграции компоненты по определению независими, повлиять на их развитие невозможно или нецелесообразно, поэтому трансформация должна выполняться в миддле
"в идеале, каждый строительный блок решения должен быть чёрным ящиком с контрактом, тогда он будет независимым и автономным"
источник

I

Ivan in Архитектура ИТ-решений
Vitaly U
В моем случая вопрос где разместить этот транслятор, а не что делать с форматами
Положение транслятора достаточно определено. Насколько я вас понял, то вопрос стоит Translator vs Message Mapper https://www.enterpriseintegrationpatterns.com/patterns/messaging/MessagingMapper.html
В любом случае, если такой вопрос возник, то, по всей вероятности, вы не получили представления об Anti-Corruption Layer, так как он транслятор не использует.
источник

VU

Vitaly U in Архитектура ИТ-решений
Vitaly U
Как вы считаете, в чей области ответственности должна быть трансформация данных из вне?
Есть системы потребляющие данные внешних систем (относительно организации), есть мидлвейр, обеспечивающий доставку данных в формате внешних систем, где должна быть трансформация в конечные используемые структуры, в мидлвейре или в конечных системах?
@emacsway
Нет же, вот вопрос, вы видимо не туда посмотрели
источник

VU

Vitaly U in Архитектура ИТ-решений
Или я так выразился неудачно
источник

EI

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

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

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

F

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

F

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

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

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

F

Fagor in Архитектура ИТ-решений
Кросс проверки, так же вопрос практик, по сути это уже уровень не архитектуры ландшавта, а соглашения и практики внутрии организации к командам разработки
источник