несколько команд для одиночного процесса в CQRS

Question

У меня есть приложение CQRS + ES. Это я новый CQRS + ES мир читал на нем в течение последнего года, и это имеет прекрасный смысл, но реализация идеального смысла не всегда легко.

в любом случае мой вопрос или вопросы:

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

1. CreateUserProfileCommand
2. CreatePaymentAccountCommand
3. SendEmailAddressVerificationCommand

Я посмотрел на Саги они выглядят более начать и остановить этот процесс, который является непрерывным.

Конечно, цепочки событий могут привести к повторному кошмару.

UPDATE @EbenRoux
Чтобы добавить информацию, CreatePaymentAccount фактически должны быть именем UpdateUserWithPpaymentAccount. Я вижу путаницу в названии. То, что эта команда действительно получает третью сторону и получает PaymentCustomerId, которые привязаны к Пользователю.

Получаю, что ты говоришь о саге, и мне было интересно, нужен ли этот процесс.

В настоящее время это приложение выполняется, поэтому весь бизнес-контекст (я предполагаю, это то, что вы подразумеваете под BC), не имеет одной конечной точки pub/sub pointpoint. Я бы хотел туда добраться.

Answer 1

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

Ваш менеджер процессов (что иногда называют саги) будет первый класс гражданина в другом процессе Bounded контексте (BC), который координирует систему обмена сообщениями и его состояние может также, безусловно, будет храниться с использованием ES.

Вы можете направлять одни и те же сообщения (если хотите) на разные конечные точки из разных источников. Например: с вашего уровня интерфейса/интеграции вы можете отправить CreatUserProfileCommand, и маршрутизация отправит его в ваш процесс BC, где обработчик создает новый UserRegistrationProcess, сохраняет поток и отправляет CreateUserProfileCommand, который теперь перенаправляется на User BC.

От User до н.э. UserProfileCreatedEvent опубликована, что ваш процесс BC поддерживает и UserRegistrationProcess обновляется, поток сохраняется, и CreatePaymentAccountCommand отослан в Payment до н. Ниже приведен пример системного сообщения (события), который, вероятно, будет иметь структуру, несколько отличающуюся от структуры, созданной для сторон ES.

Теперь из Payment BC опубликован PaymentAccountCreatedEvent, который также подписывается процессом BC, а SendEMailAddressVerificationCommand отправляется в соответствующий BC.

Достаточно общий узор.

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

Answer 2

Это один случай использования? I.e Создание профиля пользователя?

Мне интересно, почему не просто одна команда CreateUserProfile, которая затем обрабатывается обработчиком команд, который организует прецедент. Все остальное станет событиями I.e. PaymentAccountCreated, EmailNotificationSent и т. Д.

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

Answer 3

События не являются кошмаром, они как раз то, как все работает в реальной жизни. Если вы отправляете письмо, вы не ждете ответа, вы продолжаете свою жизнь, и когда вы получите ответ, вы получите письмо и прочтете его.

Вы действительно можете использовать сагу.

1. Инициировать сагу с CreateUserProfileCommand
2. Опубликовать новое событие UserProfileCreatedStarted и есть платежи обслуживание слушать это событие
3. сделать регистрацию сага подписаться на «PaymentAccountCreatedEvent»
4. Опубликовать UserProfileCommandCreated, когда процесс регистрации завершен
5. Опубликовать «UserProfileCommandCreated» и завершить сагу и
6. Попросите услугу связи подписаться на UserProfileCommandCreated и отправить электронную почту

Посмотрите на этот пример: Saga implementation patterns – variations

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

Что касается источников событий и поскольку это все ново для вас, смотрите здесь: best event sourcing db strategy