事件溯源中的事件消费者和重复代码
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?
似乎是的,它可能是事件溯源的情况。