事件溯源中的事件消费者和重复代码

Question

我对事件溯源还很陌生，我们有一个域，我们考虑在其上应用事件溯源。

我们有一个应用程序将域事件存储到Oracle DB 和事件的消费者将使用它们来生成读取模型（所有读取模型都将在内存中生成），这些消费者将主要使用轮询模型来获取事件。

这意味着他们将收到一个请求，并根据该请求消费一个事件流并生成他们的读取模型，然后将其返回给调用者。

例如

Event Generation API --> 为类型 A 的聚合生成事件并将它们存储在 Oracle DB 中。

Consumer 1 --> 获取特定类型 A 聚合的请求，然后获取事件并重放它们以准备其读取模型。

Consumer 2 --> 做同样的事情，但呈现不同的读取模型

我们为什么要使用 ES

1. 我们需要提供每次更改的数据历史表示形式以及该更改时的聚合状态。
2. 我们需要能够在每个事件的任何时间点获取聚合的快照，例如，在更改名称时，我们需要该名称更改事件时间的聚合状态
3. 我们需要表示时间点之间聚合状态的差异

但是所有这些要求都需要以轮询的方式完成，这意味着消费者将在某个时间点请求视图（可能是最新的或以前的）

问题 1

既然consumer 1 和consumer 2 都将执行基本相同的逻辑来重放事件，那么重放事件的代码应该在哪里呢？我们会实现一个通用的库代码吗？这是否意味着我们将在消费者之间拥有重复的重放代码？

我担心当我们更新一个事件架构时，我们需要更新多个消费者

问题 2

这是一个很好的事件溯源案例吗？

Answer 1

这意味着他们将收到一个请求，并根据该请求消费一个事件流并生成他们的读取模型，然后将其返回给调用者。

这是一种奇怪的 Read 模型，至少对我来说是这样。它似乎不是很快，速度是读取模型的优势之一。

一般来说，Read 模型尽可能早地在后台处理事件（即在它们发出后的毫秒内）；结果保存在一个快速的数据库中（在磁盘或内存上），应用了所有索引，因此当请求到来时，响应很快。

1. 我们需要为每次更改提供数据的历史表示形式以及该更改时的聚合状态。

2. 我们需要能够在每个事件的任何时间点获取聚合的快照，例如，更改名称，然后我们需要该名称更改事件的状态

   李>

Aggregate 的状态应该是隐藏的、私有的——Aggregate 需要高级别的封装。也许您需要对在此之前生成的事件进行解释：这是读取模型的职责。聚合仅使用状态来决定是否以及在下一个命令中将生成哪些事件。

因此，我建议您设计一个读取模型来完全做到这一点：它为每个聚合维护另一个状态，在一个平面（非事件源）持久性中。

1. 我们需要表示时间点之间聚合状态的差异

同样，这应该由读取模型完成。

既然消费者 1 和消费者 2 都将执行基本相同的逻辑来重放事件，那么重放事件的代码应该在哪里呢？我们会实现一个通用的库代码吗？这是否意味着我们将在消费者之间拥有重复的重放代码？

但后来你说：Consumer 2 --> does exactly the same thing but presents a different read model。这意味着他们基本上不会做同样的事情。如果您指的是从事件存储中获取事件并提供给消费者的代码，那么是的，您可以将它放在一个公共库中。

我担心我们在更新事件架构时需要更新多个消费者

这是一个问题，但有multiple solutions。

这是一个很好的事件溯源案例吗？

似乎是的，它可能是事件溯源的一个案例。