我对事件采购很陌生，我们有一个域名，我们考虑应用事件采购。
我们有一个应用程序，它将域事件存储到Oracle DB以及将使用它们生成读取模型的事件的消费者（所有读取模型将在内存中生成），这些消费者将主要使用用于获取事件的轮询模型。
这意味着他们将获得一个请求，并根据该请求，他们将使用一系列事件并生成他们的读取模型，然后将其返回给调用者。
所以例如
Event Generation API - ＆gt;为A类聚合生成事件，并将它们存储在Oracle DB中。
Consumer 1 - ＆gt;获取某个类型A聚合的请求，然后它获取事件并重放它们以准备它的读取模型。
Consumer 2 - ＆gt;完全相同但提出了不同的阅读模型
为什么我们使用ES
但所有这些要求都需要以投票方式完成，这意味着消费者将在某个时间点（可能是最新的或前一个）请求视图
问题1
由于consumer 1和consumer 2将执行基本相同的逻辑来重放事件，那么重放事件的代码应该在哪里？我们会实现一个通用的库代码吗？这是否意味着我们将在消费者中重复使用重播代码？
我担心当我们更新事件架构时，我们需要更新多个消费者
问题2
这是事件采购的好例子吗？
答案 0 :(得分：3)
这意味着他们将获得一个请求，并根据该请求，他们将使用一系列事件并生成他们的读取模型，然后将其返回给调用者。
这是一种奇怪的Read模型，至少对我而言。它似乎不是很快，速度是Read模型的优势之一。
通常，Read模型尽可能早地处理事件中的事件（即发出后的毫秒）;结果将保存在快速数据库（磁盘或内存）上，并应用所有索引，以便在请求到来时响应速度很快。
我们需要提供每次更改的数据的历史表示以及该更改时的聚合状态。
我们需要能够在每个事件的任何时间点获取聚合的快照，例如，更改名称，然后我们需要在该名称更改事件的状态
Aggregate的状态应该是隐藏的，私有的 - Aggregate需要高级别的封装。也许你需要解释直到那时产生的事件：这是Read模型的责任。聚合使用仅来确定它将在下一个命令上生成的事件和事件。
所以，我建议你设计一个完全符合它的Read模型：它以平坦（非事件源）持久性为每个Aggregate维护另一个状态。
- 我们需要表示时间点之间聚合状态的差异
同样，这应该由Read模型完成。
由于消费者1和消费者2都要执行基本相同的逻辑来重放事件，那么重放事件的代码应该在哪里？我们会实现一个通用的库代码吗？这是否意味着我们将在消费者中重复使用重播代码？
然后你说：Consumer 2 --> does exactly the same thing but presents a different read model。这意味着他们基本上不会做同样的事情。如果您指的是从事件存储中提取事件并为消费者提供信息的代码，那么您可以将其放在公共库中。
我担心我们在更新我们的事件架构时需要更新多个消费者
这是问题，但有multiple solutions。
这是事件采购的好例子吗？
似乎是，可能是事件来源的案例。