事件溯源关系和基础知识
event sourcing relationships and basics
我在一家初创公司工作，我们希望通过事件溯源构建一个基本的概念验证。谁能就这些基本问题提供一些说明？
- 事件源是事件流的集合吗？
- 每个限界上下文都有一个事件源吗？或者也许每个 DDD 聚合（比如汽车及其变化）？
- 每个事件源是否都有自己的数据存储？
- 一个例子是汽车的事件源，其中每个事件流都基于唯一的 carId 吗？
关于可能的基本流程的问题...这听起来完整且有意义吗？
client --> eventStore API --> 存储事件 --> 可能将消息发布到队列 --> Ack to client 竖起大拇指 --> go build your read models/indexes? --> 客户端公开发布事件 --> 同一事件的其他消费者现在可以根据事件采取行动。
我对 "build read models" 部分不是很清楚...我想您可以在任何单独的数据存储中构建 "projections"？或者只是索引实际事件存储中的数据以便快速查询？
如能对这些问题进行澄清，那就太好了。
谢谢！
-罗恩
我会给你一些我ve-used/seen-used的基本事件溯源术语。此外，我将在 CQRS 上下文中使用事件溯源，尽管它可以单独使用（我直到现在才这样做）。
事件存储是事件的持久性（数据库）。应用程序的 write/command 和 read/query 端对事件存储有不同的要求。
写入端需要聚合发出的事件必须有序并且受到保护免受并发插入。人们称之为 事件流 = 聚合实例（即 Product#1234）发出的所有事件。 Event流在读取的时候也应该很快，即从Event流中读取所有的事件，按照事件发出的顺序，最早的在前，应该很快；在执行每个命令之前，这是聚合再水化所必需的。
读取方希望所有事件在所有聚合中按 总 顺序排列。如果你能满足这个要求，那么 Readmodels 的构建就更简单了。但是，通过更大的开发+设计工作，可以创建不需要全序的读取模型。
大系统的问题是，通常，读取模型需要来自多个事件存储的事件
Is an event source a collection of event streams?
如果 "event source" 你的意思是 "Event store"，那么是。
Would you have an event source per bounded context? Or maybe per DDD Aggregate(like for a car and its changes)?
最简单的系统是具有单个事件存储实例的系统。这是因为 Readmodels 然后只需要连接到一个实例，并且您可以拥有一个事件的总顺序。
如果系统太大，不可能有一个单一的事件存储。这意味着您不能拥有完整的事件顺序，这意味着 Readmodels 更难构建（并非不可能）并且运营成本增加。
所以，你必须做出取舍。一个不错的权衡是每个有界上下文都有一个事件存储。
Would each event source have its own data store?
这个问题在这个答案的上下文中没有意义。一个事件存储 = 一个数据存储。
Would an example be an event source of a car, where each event stream is based on a unique carId?
是的，每个汽车实例（具有唯一 ID）都有一个事件流。
client --> eventStore API --> store the event --> maybe publish a message to a queue --> Ack to client giving a thumbs up --> go build your read models/indexes? --> client publishes the event publicly --> other consumers of that same event now can take action based on the event.
这取决于您的 architecture/style/how Readmodels 接收事件。
你可能有一个简单的同步系统，当在同一个 process/thread 中处理一个命令，发出事件，它们立即被持久化到事件存储中，然后所有的 Readmodels 和 Sagas 被提供有了这些新事件，所有事件都同步进行，一个接一个。
一个更复杂的系统执行命令，将事件保存到事件存储，然后 returns 对客户端的响应。在一个单独的进程中，Readmodels 和 Sagas 从 Event store（它提供了这样一个API）轮询新事件并在后台处理它们。
其他解决方案使用消息队列；这有点难做，因为不能安全地以可扩展的方式将事件持久保存到事件存储 和 以原子方式将它们发布到消息队列（都成功或 none).
我在一家初创公司工作，我们希望通过事件溯源构建一个基本的概念验证。谁能就这些基本问题提供一些说明？
- 事件源是事件流的集合吗？
- 每个限界上下文都有一个事件源吗？或者也许每个 DDD 聚合（比如汽车及其变化）？
- 每个事件源是否都有自己的数据存储？
- 一个例子是汽车的事件源，其中每个事件流都基于唯一的 carId 吗？
关于可能的基本流程的问题...这听起来完整且有意义吗？
client --> eventStore API --> 存储事件 --> 可能将消息发布到队列 --> Ack to client 竖起大拇指 --> go build your read models/indexes? --> 客户端公开发布事件 --> 同一事件的其他消费者现在可以根据事件采取行动。
我对 "build read models" 部分不是很清楚...我想您可以在任何单独的数据存储中构建 "projections"？或者只是索引实际事件存储中的数据以便快速查询？
如能对这些问题进行澄清，那就太好了。
谢谢！ -罗恩
我会给你一些我ve-used/seen-used的基本事件溯源术语。此外，我将在 CQRS 上下文中使用事件溯源，尽管它可以单独使用（我直到现在才这样做）。
事件存储是事件的持久性（数据库）。应用程序的 write/command 和 read/query 端对事件存储有不同的要求。
写入端需要聚合发出的事件必须有序并且受到保护免受并发插入。人们称之为 事件流 = 聚合实例（即 Product#1234）发出的所有事件。 Event流在读取的时候也应该很快，即从Event流中读取所有的事件，按照事件发出的顺序，最早的在前，应该很快；在执行每个命令之前，这是聚合再水化所必需的。
读取方希望所有事件在所有聚合中按 总 顺序排列。如果你能满足这个要求，那么 Readmodels 的构建就更简单了。但是，通过更大的开发+设计工作，可以创建不需要全序的读取模型。
大系统的问题是，通常，读取模型需要来自多个事件存储的事件
Is an event source a collection of event streams?
如果 "event source" 你的意思是 "Event store"，那么是。
Would you have an event source per bounded context? Or maybe per DDD Aggregate(like for a car and its changes)?
最简单的系统是具有单个事件存储实例的系统。这是因为 Readmodels 然后只需要连接到一个实例，并且您可以拥有一个事件的总顺序。
如果系统太大，不可能有一个单一的事件存储。这意味着您不能拥有完整的事件顺序，这意味着 Readmodels 更难构建（并非不可能）并且运营成本增加。
所以，你必须做出取舍。一个不错的权衡是每个有界上下文都有一个事件存储。
Would each event source have its own data store?
这个问题在这个答案的上下文中没有意义。一个事件存储 = 一个数据存储。
Would an example be an event source of a car, where each event stream is based on a unique carId?
是的，每个汽车实例（具有唯一 ID）都有一个事件流。
client --> eventStore API --> store the event --> maybe publish a message to a queue --> Ack to client giving a thumbs up --> go build your read models/indexes? --> client publishes the event publicly --> other consumers of that same event now can take action based on the event.
这取决于您的 architecture/style/how Readmodels 接收事件。
你可能有一个简单的同步系统，当在同一个 process/thread 中处理一个命令，发出事件，它们立即被持久化到事件存储中，然后所有的 Readmodels 和 Sagas 被提供有了这些新事件，所有事件都同步进行，一个接一个。
一个更复杂的系统执行命令，将事件保存到事件存储，然后 returns 对客户端的响应。在一个单独的进程中，Readmodels 和 Sagas 从 Event store（它提供了这样一个API）轮询新事件并在后台处理它们。
其他解决方案使用消息队列；这有点难做，因为不能安全地以可扩展的方式将事件持久保存到事件存储 和 以原子方式将它们发布到消息队列（都成功或 none).