事件溯源中的事件消费者和重复代码
Event Consumers in Event Sourcing and duplicate code
我对事件溯源还很陌生，我们有一个领域正在考虑应用事件溯源。
我们有一个将领域事件存储到 Oracle DB 的应用程序，事件的消费者将使用它们生成读取模型（所有读取模型都将在内存中生成），这些消费者将主要使用轮询模型来获取事件。
这意味着他们将收到一个请求，并根据该请求使用事件流并生成他们的读取模型，然后 return 将其发送给调用者。
例如
Event Generation API --> 为类型 A 的聚合生成事件并将它们存储在 Oracle 数据库中。
Consumer 1 --> 获取对特定类型 A 聚合的请求，然后它获取事件并重播它们以准备它的读取模型。
Consumer 2 --> 做同样的事情，但呈现不同的读取模型
我们为什么要使用 ES
- 我们需要提供每次更改的数据历史表示以及该更改时的聚合状态。
- 我们需要能够在每个事件的任何时间点获取聚合的快照，例如，当更改名称时，我们需要该名称更改事件时间的聚合状态
- 我们需要表示时间点之间聚合状态的差异
但是所有这些需求都需要以轮询的方式完成，这意味着消费者会在某个时间点（可以是最新的或之前的）请求视图
问题 1
既然consumer 1和consumer 2都将执行基本相同的逻辑来重放事件，那么重放事件的代码应该放在哪里呢？我们会实现一个通用的库代码吗？这是否意味着我们将在消费者之间拥有重复的重播代码？
我担心当我们更新一个事件模式时我们需要更新多个消费者
问题二
这是事件溯源的好案例吗？
Which means that they will get a request and based on that request they will consume a stream of events and generate their read model then return it to the caller.
这是一种奇怪的读取模型，至少对我来说是这样。好像不是很快，速度是Read模型的强项之一。
一般来说，Read models 尽可能早的在后台处理事件（即事件发出后的几毫秒）；结果保存在快速数据库中（在磁盘或内存上），并应用所有索引，因此当请求到来时响应很快。
We need to provide historical representations of data with each change and the state of the aggregate at that change.
We need to be able to get a snapshot of an aggregate at any point in time per event basis, for example, changing a name, then we need the state at that name changed event
聚合的状态应该是隐藏的、私有的——聚合需要高级别的封装。也许您需要对到那时为止生成的事件进行解释：这是读取模型的责任。聚合使用 仅 状态来决定它是否会在下一个命令中生成以及生成哪些事件。
因此，我建议您设计一个读取模型来执行此操作：它以平面（非事件源）持久性为每个聚合维护另一个状态。
- We need to represent the diff of the state of the aggregate between points in time
同样，这应该由读取模型完成。
Since both consumer 1 and consumer 2 are going to execute basically the same logic to replay the events, then where should the code for replaying the events be? Will we implement a common library code? Does this mean that we will have duplicate replay code across consumers?
但后来你说：Consumer 2 --> does exactly the same thing but presents a different read model。这意味着他们基本上不做同样的事情。如果您指的是从事件存储中获取事件并提供给消费者的代码，那么是的，您可以将其放在公共库中。
I am worried that we when update our event schema we need to update multiple consumers
这是一个 问题 但是 multiple solutions。
Is this a good case of event sourcing?
似乎是的，它可能是事件溯源的情况。
我对事件溯源还很陌生，我们有一个领域正在考虑应用事件溯源。
我们有一个将领域事件存储到 Oracle DB 的应用程序，事件的消费者将使用它们生成读取模型（所有读取模型都将在内存中生成），这些消费者将主要使用轮询模型来获取事件。
这意味着他们将收到一个请求，并根据该请求使用事件流并生成他们的读取模型，然后 return 将其发送给调用者。
例如
Event Generation API --> 为类型 A 的聚合生成事件并将它们存储在 Oracle 数据库中。
Consumer 1 --> 获取对特定类型 A 聚合的请求，然后它获取事件并重播它们以准备它的读取模型。
Consumer 2 --> 做同样的事情，但呈现不同的读取模型
我们为什么要使用 ES
- 我们需要提供每次更改的数据历史表示以及该更改时的聚合状态。
- 我们需要能够在每个事件的任何时间点获取聚合的快照，例如，当更改名称时，我们需要该名称更改事件时间的聚合状态
- 我们需要表示时间点之间聚合状态的差异
但是所有这些需求都需要以轮询的方式完成，这意味着消费者会在某个时间点（可以是最新的或之前的）请求视图
问题 1
既然consumer 1和consumer 2都将执行基本相同的逻辑来重放事件，那么重放事件的代码应该放在哪里呢？我们会实现一个通用的库代码吗？这是否意味着我们将在消费者之间拥有重复的重播代码？
我担心当我们更新一个事件模式时我们需要更新多个消费者
问题二
这是事件溯源的好案例吗？
Which means that they will get a request and based on that request they will consume a stream of events and generate their read model then return it to the caller.
这是一种奇怪的读取模型，至少对我来说是这样。好像不是很快，速度是Read模型的强项之一。
一般来说，Read models 尽可能早的在后台处理事件（即事件发出后的几毫秒）；结果保存在快速数据库中（在磁盘或内存上），并应用所有索引，因此当请求到来时响应很快。
We need to provide historical representations of data with each change and the state of the aggregate at that change.
We need to be able to get a snapshot of an aggregate at any point in time per event basis, for example, changing a name, then we need the state at that name changed event
聚合的状态应该是隐藏的、私有的——聚合需要高级别的封装。也许您需要对到那时为止生成的事件进行解释：这是读取模型的责任。聚合使用 仅 状态来决定它是否会在下一个命令中生成以及生成哪些事件。
因此，我建议您设计一个读取模型来执行此操作：它以平面（非事件源）持久性为每个聚合维护另一个状态。
- We need to represent the diff of the state of the aggregate between points in time
同样，这应该由读取模型完成。
Since both consumer 1 and consumer 2 are going to execute basically the same logic to replay the events, then where should the code for replaying the events be? Will we implement a common library code? Does this mean that we will have duplicate replay code across consumers?
但后来你说：Consumer 2 --> does exactly the same thing but presents a different read model。这意味着他们基本上不做同样的事情。如果您指的是从事件存储中获取事件并提供给消费者的代码，那么是的，您可以将其放在公共库中。
I am worried that we when update our event schema we need to update multiple consumers
这是一个 问题 但是 multiple solutions。
Is this a good case of event sourcing?
似乎是的，它可能是事件溯源的情况。