Инфраструктура, обеспечивающая интеграцию ограниченных контекстов с обменом сообщениями и веб-сервисами.

Во время моего первого набега на интеграцию систем я определил следующие ограниченные контексты:

  1. Выставление счетов
  2. Подписки
  3. Коллекции

В частности, для функции «приостанавливает просроченные учетные записи» ограниченного контекста коллекций мы бы:

  1. Получить список просроченных счетов из Invoicing
  2. Отправить пользователю уведомление о приостановке (внутренняя служба электронной почты)
  3. Отправить запрошенную приостановку в ограниченном контексте подписок

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

Я знаю о шинах сообщений, но не уверен, как мы будем интегрироваться со стратегией сообщений:

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

При использовании сообщений создаем ли мы буквально локальную копию объекта (с полями использования для локального контекста) из интересующего удаленного контекста? Или я что-то еще упускаю?


domain-driven-design bounded-contexts
person morleyc    schedule 17.04.2013    source источник
comment
Архитектура, управляемая сообщениями, а точнее шаблон событий предметной области, предназначен для решения этой проблемы. Ограниченный контекст будет хранить только релевантные данные для своего собственного контекста, то есть не будет копией того, что другой BC считает моделью. Ваш "вопрос" слишком локализован и весьма спорен   -  person MikeSW    schedule 17.04.2013

Ответы (1)


arrow_upward
1
arrow_downward

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

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

person eulerfx    schedule 17.04.2013
comment
Это очень полезно, спасибо. Что, если бы мы захотели определить CollectionStrategy (для каждой учетной записи клиента), которая определяла бы действия, которые необходимо предпринять (например, за 10 дней до отправки напоминания. Напоминание по электронной почте о дате выставления счета. Через 3 дня по электронной почте и SMS. Приостановка на 5 дней) , будем ли мы публиковать InvoiceIsDaysOverdue для каждого счета из Invoices, или было бы лучше, чтобы Collections поддерживали свой собственный список подлежащих оплате счетов (через события или через веб-сервис GetInvoicesDue)? - person morleyc; 17.04.2013
comment
Если за отправку уведомлений о сроках и просроченных платежах отвечает BC Collections, то необходимо подписаться на событие InvoiceCreated (и InvoiceRemoved, если применимо). Затем он будет хранить дату выполнения, и на основе этой даты вы можете запускать различные события, такие как срок через неделю или просроченный срок. - person eulerfx; 17.04.2013
comment
Invoicing BC — это облачная система учета (которая может измениться в будущем). Я напишу промежуточное ПО, которое опрашивает приложение для выставления счетов и генерирует из него события. Не уверен, как будет называться эта промежуточная архитектура, но наверняка она решит множество проблем и неприятный код проверки ошибок. Вы, очевидно, обладаете большим умением определять концепции предметной области - есть ли какие-либо онлайн-ссылки для чтения и изучения, или это просто вопрос опыта? - person morleyc; 17.04.2013
comment
Для EDA о моделировании предметной области см. msdn.microsoft.com/en -us/architecture/aa699424.aspx. Также для DDD в целом — amazon.com/Implementing-Domain- Driven-Design-Вон-Вернон/dp/ - person eulerfx; 17.04.2013
comment
Последующий запрос: если мы подпишемся на события InvoiceCreated и сохраним дату выполнения внутри BC Collections, будут ли эти даты храниться в корне сущности внутри BC Collections или в модели чтения? - person morleyc; 18.04.2013