CQRS и уведомление по электронной почте

Question

CQRS и уведомление по электронной почте

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

Конкретные шаги могли бы пойти как это:

A CreateEvent команда со связанным набором пользователей для приглашения, получен сервером.
Новое Meeting агрегат создается и метод InviteUser назван для каждого пользователя, который должен быть приглашен.
Каждый раз пользователь приглашен в событие, доменное событие UserWasInvitedToEvent повышен.
Отправитель уведомления по электронной почте берет доменное событие и отсылает уведомление по электронной почте.

Теперь мой вопрос - это: Куда я иду, чтобы информация включала в электронную почту?

Скажите, что я хочу включать описание события, а также имени пользователя. Так как это - CQRS, я не могу получить его через свою модель предметной области; Все собственности объектов области являются частными! Я должен затем запросить сторону чтения? Или, возможно, переместите уведомление по электронной почте в другую службу полностью?

6

email domain-driven-design notifications cqrs

задан Ruben Bartelink 9 August 2012 в 00:20

1 ответ

Другие вопросы по тегам:

email domain-driven-design notifications cqrs

Похожие вопросы:

score 6 · Answer 1

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

Домен должен зарегистрироваться и отправить событие EventCreated обработчикам / процессорам событий. Это может быть вызвано конструктором агрегата Meeting .
Компонент обработки событий выбирает событие EventCreated и обновляет базу данных запросов данными, содержащимися в событии (т. Е. Идентификатором события и его именем).
Домен может зарегистрироваться и отправить событие UserWasInvitedToEvent обработчикам событий.
Обработчики событий собирают UserWasInvitedToEvent и обновляют хранилище запросов любыми необходимыми отчетными данными.
Другой компонент обработки событий также перехватит событие UserWasInvitedToEvent . Этот процесс может иметь доступ к базе данных запросов и получать все данные, необходимые для отправки электронного письма.

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

Чтобы организовать несколько различных событий в одном обработчике (при условии, что события могут обрабатываться в разном порядке в разное время), вы можете использовать концепцию Saga в своей шине обмена сообщениями. NServiceBus - это пример шины обмена сообщениями, которая поддерживает Saga. См. Также этот вопрос StackOverflow: NServiceBus Delayed Message Processing .