Поиск событий с побочными эффектами

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

  1. Запрос получен.
  2. Загружается история агрегата.
  3. Агрегат перестраивается (из его истории).
  4. Готовятся новые события, и агрегат обновляется в ответ на входящий запрос с шага 1.
  5. Эти события записываются в журнал и становятся доступными (публикуются) всем подписчикам.

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

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

Как мне обработать это в коде?

Вариант 1. Не записывать побочные события в журнал событий. Опубликуйте их в основном процессе перед Шагом 5.

Вариант 2. Записывайте все в журнал событий и игнорируйте побочные события при загрузке истории. (Это не часть истории!)

Вариант 3. Записывайте побочные события в фиктивный агрегат, чтобы они публиковались, но никогда не загружались.

Вариант 4-?

В первом варианте могут возникнуть проблемы при нарушении параллелизма. Если запись не удалась на шаге 5, побочный эффект не может быть легко отменен. Второй вариант записывает события, которые не являются частью истории агрегата. При загрузке на шаге 2 эти побочные события необходимо игнорировать. Третий вариант похож на взлом.

Что из этого кажется вам правильным?


event-sourcing event-driven-design domain-driven-design
person Charles R    schedule 04.01.2016    source источник
comment
Обычно вы выбираете вариант 2. Допустим, у вас есть приложение с источником событий, например банковская статистика и статистика второго приложения, которая строит статистику на основе событий, произошедших в первом приложении. Скажем, статистическое приложение подписывается на ваше побочное событие. Все будет работать без сохранения этого события, пока ваш бизнес не скажет: «Мы хотим продавать их как отдельные системы». Теперь ваш клиент после двух лет использования банковского приложения купит статистическое приложение, если вы не сохраните свои побочные эффекты раньше в ES, вы пропустите какую-то концепцию или даже не справитесь с синхронизацией.   -  person Dariss    schedule 05.01.2016
comment
@CharlesR, можете ли вы привести конкретные примеры таких побочных эффектов? Я не уверен, почему то, что не влияет на состояние какого-либо агрегата, в первую очередь следует рассматривать как событие предметной области ...   -  person guillaume31    schedule 05.01.2016
comment
@ guillaume31 Совокупная сумма - это сумма партнерской задолженности. Это деньги, которые были отправлены, и нам нужно их вернуть. Вместо того, чтобы выставлять счет клиенту напрямую, мы берем это из будущих денег, которые мы ему отправим. Перед распределением средств мы проверяем, должен ли партнер деньги, и забираем то, что он должен. Затем мы публикуем события домена, чтобы обновить баланс денежных средств партнера и распределить любые средства. С точки зрения этой службы, это запросы или побочные эффекты. Их нужно опубликовать, но они не влияют на состояние агрегата (размер задолженности партнера).   -  person Charles R    schedule 05.01.2016
comment
Я не уверен насчет порядка событий здесь. Если я вас поправлю, вы говорите, что PartnerAmountOwed.Reduced должен вызвать PartnerCashBalance.Update() и Funds.Distribute(). Я бы сделал наоборот.   -  person guillaume31    schedule 06.01.2016
comment
Кроме Нам нужно их опубликовать, конечно, но агрегат PartnerAmountOwed не должен их публиковать. Он должен не знать о побочных эффектах, которые проявляются в других агрегатах, и придерживаться своего собственного внутреннего повсеместного языка и событий.   -  person guillaume31    schedule 06.01.2016

Ответы (3)


arrow_upward
5
arrow_downward

Назовите события правильно

События - это «вещи, которые произошли». Таким образом, если вы можете назвать события, которые вызывают только побочные эффекты, в стиле «X произошло», они станут естественной частью истории событий.

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

Что касается вашего списка альтернатив, это будет вариант 2.

Пример

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

person theDmi    schedule 05.01.2016

arrow_upward
1
arrow_downward

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

События должны быть детализированными.

person KarlM    schedule 05.01.2016

arrow_upward
0
arrow_downward

Вариант 1. Не записывать побочные события в журнал событий. Опубликуйте их в основном процессе перед Шагом 5.

Что, если позже вам понадобится эта часть истории для создания нового ограниченного контекста?

Вариант 2. Записывайте все в журнал событий и игнорируйте побочные события при загрузке истории. (Это не часть истории!)

Как игнорировать влияние чего-то, что не имеет никакого эффекта? : D

Вариант 3. Записывайте побочные события в фиктивный агрегат, чтобы они публиковались, но никогда не загружались.

Зачем вам нужна граница согласованности вокруг чего-то, что вы никогда не измените?

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

person inf3rno    schedule 09.01.2016