Как получить данные из другого ограниченного контекста в DDD?

Question

Изначально приложение запускается на рабочем столе, однако в будущем оно будет работать на веб-платформе.

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

Я подумал об использовании шаблона посредника, в котором связанный контекст «A» запрашивает данные «X», а затем посредник вызывает другой связанный контекст, например B «», и получает правильные данные «X».Наконец, посредник переносит данные «X» в BC «A».

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

Интересны оба подхода или есть другое лучшее решение?

Может ли кто-нибудь мне помочь, пожалуйста?

Большое спасибо!

Answer 1

Вам нужен шаблон DDD для интеграции.BC «B» вверх по течению, «A» вниз по течению.Вы можете выбрать OHS PL в восходящем и ACL в нисходящем.На практике это REST API upstream и адаптер downstream.Каждый раз, когда A требует данные от B, адаптер вызывает REST API и адаптирует информацию, возвращаемую к модели домена A.Это было бы синхронизировано.Если вы хотите использовать асинхронную интеграцию, B будет публиковать события в MQ с информацией, а A будет прослушивать эти события и получать информацию.

Answer 2

Ответ на этот вопрос разбивается на две отдельные области:

• логическая задача взаимодействия между различными контекстами, где одни и те же данные могут использоваться совершенно по-разному,Как один контекст интерпретирует значение данных?
• и техническую задачу синхронизации данных между независимыми системами.Как мы можем гарантировать правильность поведения каждой системы, когда обе они имеют независимые копии «одинаковых» данных?

Логически карта контекста используется для определения взаимосвязи между любыми ограниченными контекстами, которые необходимообщаться (обмениваться данными) любым способом.Модели предметной области, управляющие данными, применимы только в одном ограниченном контексте, поэтому необходим некоторый метод для интерпретации данных из другого контекста.Вот где в игру вступают паттерны из книги Эвана: клиент / поставщик, конформист, публикуемый язык, открытый хост, антикоррупционный уровень или (паттерн отговорки) отдельные пути.

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

С технической точки зрения прямые вызовы API между сервисами в разных ограниченных контекстах вводят зависимости между этими сервисами, поэтому управляемые событиямиПодход, подобный тому, о котором упоминал Аллан, предпочтителен, если предположить, что с вашим приложением все в порядке (возможная согласованность данных).Выбор платформы обмена сообщениями, которая дает вам гарантии, необходимые для синхронизации данных, очень важен.Большинство протоколов асинхронного обмена сообщениями гарантируют доставку «хотя бы один раз», но упорядочение сообщений и дедупликация повторений зависит от приложения.

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

Составной пользовательский интерфейс - это еще один шаблон, который позволяет выполнять интеграцию данных на уровне представления,заставляя каждый компонент извлекать данные из соответствующей службы, а затем делиться / объединять данные в самом пользовательском интерфейсе.Это может быть проще в управлении, чем запутанная сеть межсервисных API-вызовов в бэкэнде, особенно если вы используете что-то вроде службы IT / Ops, NGINX или MuleSoft's Experience API, чтобы реализовать «бэкэнд для внешнего интерфейса».

Answer 3

Если вы извлекаете данные из других, ограниченных через вызовы БД или API, ваша архитектура может потенциально упасть до паттерна смерти, потому что она привносит нежелательные связи и знания в контекст клиента.

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

Это дает вам ощущение «Кому интересно, если ограниченный контекст B недоступен» ATM, ограниченный контекст A и C содержит данные, которые им нужны, и я могу возобновить синхронизацию позже, так как события, связанные с обновлением данных, записываются в мою очередь "