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

这意味着他们将获得一个请求,并根据该请求使用一个事件流,生成其读取模型,然后将其返回给调用者。

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

一般来说,Read模型会尽早在后台处理事件(即在事件发出后的毫秒);结果保存在一个快速的数据库(磁盘或内存)中,并应用所有索引,因此当请求到来时,响应速度很快。

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

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

聚合的状态应该是隐藏的、私有的-聚合需要高级别的封装。也许您需要对在此之前生成的事件进行解释:这是阅读模型的责任。使用状态 只有 由聚合来决定是否以及它将在下一个命令上生成什么事件。

因此,我建议您设计一个读取模型,该模型正好做到这一点:它在一个平面(非事件源)持久性中为每个聚合维护另一个状态。

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

同样,这应该通过读取模型来完成。

由于使用者1和使用者2都将执行基本相同的逻辑来重播事件,那么重播事件的代码应该在哪里?我们会实现一个公共库代码吗?这是否意味着我们将在消费者之间拥有重复的重播代码?

但是你说: Consumer 2 --> does exactly the same thing but presents a different read model . 这意味着他们基本上不会做同样的事情。如果您引用的是从事件存储中获取事件并向使用者提供信息的代码,那么可以将其放在公共库中。

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

这是一个 问题 但有一个 multiple solutions .

这是一个很好的活动采购案例吗?

看来是的 也许 以活动采购为例。