event-sourcing - 是否可以将弹簧状态机与事件源模式结合起来？

Question

我的想法是通过弹簧状态机跟踪域对象的状态。即状态机定义如何传输域对象的状态。当事件被持久化/从事件存储中恢复时，可以通过将事件发送到状态机来（重新）生成域对象的状态。

但是，创建状态机对象似乎相对昂贵，每当域对象发生状态转换时，创建状态机对象的性能并不高。如果我只维护一个状态机对象，我会担心并发问题。一种方法是拥有一个“状态机池”，但如果我必须为多个不同的域对象创建状态机，它就会变得混乱。

那么将 spring 状态机与事件源模式一起应用是一个好主意吗？

Answer 1

如果所有转换都基于事件，我会说这是一个非常好的主意，是的。

事件溯源的基本思想是确保对应用程序状态的每一次更改都被捕获到一个事件对象中，并且这些事件对象本身按照它们被应用的顺序存储，其生命周期与应用程序状态本身相同。

关于事件溯源的要点是您存储导致特定状态的事件 - 而不仅仅是存储当前状态 - 以便您可以在给定的时间点重播它们。

因此，使用事件溯源对创建状态机的方式没有影响。

但是，创建状态机对象似乎相对昂贵，每当域对象发生状态转换时，创建状态机对象的性能并不高。

每次发生状态转换时创建状态机与事件溯源无关。如果你只存储当前状态，你会做不同的事情吗？在应用转换之前，您仍然需要从最后存储的状态创建状态机 - 或者在缓存或池中查找它。

使用事件源产生的唯一性能损失是从头开始重放转换以达到当前状态。现在，如果成本很高，您可以使用快照来最小化必须重放的转换数量。