0前言Kafka不适合事件溯源，Kafka适合消息流。这两种事物需要不同存储机制。事件溯源（EventSourcing），需DB充当事件日志，为事件溯源存储的事件必须以某种方式编写，以便将来的读取能够快速组装属于单个聚合的较小（更小的）事件流最初发射它们的。这需要随机访问索引消息流（MessageStreaming），需要的存储本质上是个记录消息元素的“flatfile”。消息元素按序单独写，然后按序读。这需要一个从第一到最后一个的顺序索引1细分除了聚合子流，事件源域模型的所有事件通常都按照聚合最初发出的时间顺序作为全序事件流。为此还需要一个顺序索引。因此，事件溯源数据库须支持两种类型的索引。

这篇文章是实现一个基于CQRS和事件溯源原则的应用程序，描述这个过程的方式，我相信分享我面临的挑战和问题可能对一些人有用。特别是如果你正在开始自己的旅程。一、业务背景项目的背景与空中交通管理（ATM）领域相关。我们为一个ANSP（航空导航服务提供商）设计了一个解决方案，负责控制特定地理区域。这个应用程序的目标很简单：计算并持久化飞行数据。流程大致如下。在飞机穿越其领空之前的几个小时，ANSP会收到来自Eurocontrol的信息，这个组织负责管理整个欧洲的航空交通。这些信息包含计划数据，如飞机类型、起飞地点、目的地、请求的航路等。一旦飞机到达了ANSP的AOR（责任区域，ANSP负责控制和监控

我写了我的项目，就是论坛的游戏Mafia。我使用CQRS事件源+MongoDB。当游戏开始时，游戏需要给每个玩家一个随机的角色。我怎么能意识到，如果聚合根将应用事件，例如，“角色给定”，来自数据库(不是事件，现在已经保存)，总是会调用随机函数，这将返回不同的结果？ 最佳答案 通常你会有一个命令来触发一些域行为(即分配随机角色)，然后角色将保存在数据库中的一个事件中，即角色分配。这将在玩家下次通过重播事件恢复游戏时保留角色。您不会在处理事件的代码中分配随机角色，它会在命令处理程序中完成，不会重播。publicvoidHandle(){