读取模型中的投影聚合状态，读取侧的额外逻辑与事件中的模式数据

Question

假设，我正在使用事件源，并且我的聚合根（匹配项）根据“ 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 Model（使用事件数据）当前得分是多少表示形式，因此读取模型会将其视为给定值并追加到桌子？在这种情况下，读取端非常简单，但是我们添加了一些不需要的额外数据到源事件中聚合自身。
• 或者，我们可以让Read一方找出分数表示形式？它会需要额外的逻辑，这将与聚合以跟踪其当前状态。

另一个问题：如果玩家赢得了积分，并且合计看到它是GamePoint，SetPoint或MatchPoint，我是否为此记录不同的事件类型，或者我只使用< [PlayerLostPoint / PlayerLostPoint事件？同样，因为聚集体可以从后两种事件类型中自身重新水合。但是，仅使用两种事件类型，读取模型就变得更加复杂（即需要跟踪游戏，布景等）。我认为添加额外的偶数类型来简化ReadModel并没有太大的危害，潜在的额外事件类型也可能对聚合有用，例如，如果最后一个点事件是“ PlayerWonTheMatch”，它可以跳过处理所有点事件？

Answer 1

我是否告诉Read Model（使用事件数据）当前得分是多少表示形式

我认为这就是您应该采取的方式。否则，您应该在读取模型上构建另一个聚合。原因只有合计知道您对分数执行了特定操作之后的分数。还应考虑事件可能会发生故障，或发生两次。为此做好准备。

[如果玩家赢得了积分，并且合计看到它是一个GamePoint，SetPoint或MatchPoint，我是否为此记录不同的事件类型？只继续使用PlayerLostPoint / PlayerLostPoint事件？

我认为如果您的域需要它，您应该这样做。它提供了有关游戏的更多详细信息，但请确保需要它，不要对现实进行编程，否则，您最终将遇到诸如ABallBoySuppliedTennisBallToPlayerEvent之类的事件，这对于您的域可能是无用的。