Разработка команд и событий при обработке внешнего партнера с Axon 4 - PullRequest
Новая
       42

Разработка команд и событий при обработке внешнего партнера с Axon 4

0 голосов
/ 21 января 2019

Это вопрос, связанный с проектированием обработки команд с помощью Axon 4.

Допустим, у меня есть домен, который моделирует концепцию Payment.

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

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

Как лучше всего называть моего партнера по Axon 4 на самом деле?

Вот что я сделал до сих пор:

  • Иметь одну команду с именем RequestPaymentCommand
  • Эта команда будет обрабатываться Payment Aggregate, подобным этому:
    • выполните некоторые проверки
    • примените событие PaymentRequestWasIssued
    • , а затем вызовите внешнего партнера и, получив результат, примените либо PaymentAccepted, либо PaymentRefused

В этом ответе от stackoverflow говорится, что

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

Имея это в виду, я подстоять, что я должен создать столько команд, сколько событий?Но в этом случае какой смысл всех этих команд?Если я получу что-то вроде:

  • Моя команда RequestPaymentCommand сгенерирует событие PaymentRequestWasIssued.
  • Затем откуда-то я позвоню своему партнеру и затем отправлю еще команда (как ее назвать?), Которая будет генерировать событие с учетом результата от партнера?

1 Ответ

0 голосов
/ 21 января 2019

Фактический платеж будет сделан внешним Партнером

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

После локального копирования удаленных событий ваша система может реагировать на них.Это может означать, что Сага после получения Partner Agreed the Payment отправляет команду UnlockFeature в локальный агрегат (см. DDD).

Имея это в виду, я понимаю, что должен создатьстолько команд, сколько событий?Но в этом случае какой смысл всех этих команд?

Это признак того, что это не ваши события: вы не должны выбрасывать их из своего кода;в худшем случае вы сохраняете их и реагируете на них (в Saga / Process manager).Это означает, что вы должны обнаружить локальные бизнес-процессы и смоделировать их так: они реагируют на события, отправляя команды.

...