Проецирование агрегатного состояния в модели чтения, дополнительные логики c на стороне чтения против большего количества данных в событии - PullRequest
Новая
       17

Проецирование агрегатного состояния в модели чтения, дополнительные логики c на стороне чтения против большего количества данных в событии

1 голос
/ 10 февраля 2020

Скажем, я использую источник событий, и мой агрегат root (match) строит свое состояние из событий "PlayerWonPoint" и "PlayerLostPoint" (у него также есть две соответствующие команды). Если упрощено, состояние изменяется от InProgress до Final . Читающая сторона отвечает за представление истории очков и некоторых статистических данных. Например, для тенниса точки будут представлены в виде 

MatchStarted    -> 0-0
PlayerWonPoint  -> 15-0
PlayerLostPoint -> 15-15
PlayerWonPoint  -> 30-15
PlayerWonPoint  -> 40-15
PlayerWonPoint  -> Player won the game
  • Должен ли я сказать модели чтения (используя данные о событиях), каково текущее представление счета, поэтому модель чтения примет это как дано и просто добавит к столу? В этом случае сторона чтения очень проста, но мы добавляем некоторые дополнительные данные в исходные события, которые на самом деле не требуются для самого агрегата.
  • Или мы можем позволить стороне Read вычислить представление результатов? Для этого потребуется дополнительная логика c, которая будет очень похожа на то, что используется в агрегате для отслеживания его текущего состояния.

Другой вопрос: если игрок выигрывает точку, а агрегат видит, что это GamePoint , SetPoint или MatchPoint , могу ли я записать другой тип события для этого или я просто продолжаю использовать только PlayerLostPoint / PlayerLostPoint события? Потому что, опять же, агрегат может повторно гидратироваться из последних двух типов событий. Но с только двумя типами событий считывание модели становится еще более сложным (т.е. необходимо отслеживать игры, наборы и т. Д. c.). Я не вижу большого вреда, добавляя дополнительные четные типы для упрощения ReadModel, потенциально дополнительные типы событий могут быть полезны и для агрегата, например, он может пропустить обработку событий всех точек, если последнее событие точки равно PlayerWonTheMatch? *

1 Ответ

1 голос
/ 10 февраля 2020

Должен ли я сказать Read Model (используя данные о событиях), каково текущее представление счета

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

, если игрок выигрывает точку, и агрегат видит, что это GamePoint, SetPoint или MatchPoint, я записываю другой тип события для этого или я просто продолжаю использовать только события PlayerLostPoint / PlayerLostPoint ?

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

...