events - 事件源: where to put business logic

Question

我可以想到将域逻辑放在事件源系统中的两个地方，其中一个都有缺点。

在Aggregate的事件处理程序中，在创建事件后在本地调用。 (这是我在大多数examples中看到的内容，尽管其中大多数具有非常简单的逻辑)
问题:存储在事件存储中并发布给订阅者的事件不包括此处理后的数据，因此在投影上，必须对事件应用相同的逻辑。

在创建事件之前。现在，已处理的数据可以存储在事件中，并且投影不必了解任何有关业务逻辑的信息。 (我没有在示例中看到此方法)
问题:在这种情况下，尽管事件仅包含已处理的数据，但可能会导致信息丢失。
更糟糕的是:由于事件数据已经计算出来，因此我还通过重播事件来释放纠正错误业务逻辑的可能性。

示例:根据某些数据计算指标。
我必须两次计算指标(在域模型中一次，在投影中一次)
否则我必须在发送事件并将其包含在其中之前对其进行计算。

Answer 1

控制流通常是这样的:

命令发送到命令处理程序，并且命令中的属性已预先验证，例如身份指向现有实体，并且所有强制性信息均以正确的格式存在

命令处理程序从存储库中检索聚合(通过读取事件流，但这并不重要)，并根据此命令需要执行的操作来调用聚合方法

聚合方法必须确保其参数和聚合状态相互允许执行该操作。

然后，

Aggregate方法创建一个事件并调用此When或Apply方法来处理事件

事件处理程序仅改变聚合状态，那里没有逻辑!

然后将控制流返回到命令处理程序，并将所有新事件保留在

存储区中

进一步的行动与预测有关。

在应用事件之前，将不变保护(也就是业务逻辑)放入聚合事件中的原因是因为生成事件时没有回头路可走。这件事已经发生了。您不能拒绝应用事件。考虑从事件流(从存储库中读取)中恢复聚合时重播事件，如果有一天您决定在那里使用 if-throw组合，这将如何工作？

因此，简而言之:

在发送命令之前应用初始逻辑

命令处理程序

中包含一些其他逻辑

聚合方法中的聚合保护(可能也可以在命令处理程序中使用)

事件处理程序中没有逻辑，只有状态突变

从来没有人说过事件源可以帮助您解决计算中的问题。为了制作一个额外的安全网，您可能需要保存命令，但是随后您将不得不发出补偿事件或截断流，这并不是您真正想做的。