如何通过场eventsourcing

Question

我是新来eventsourcing管理并发，所以这可能是一个可怕不称职的问题，所以请多多包涵：

我们有一个eventsourced，CQRS与卡桑德拉了持久化的系统。我们有一个序列号/版本号来处理聚合上的冲突修改。

我们需要一个管理接口的readmodel，它需要从几个有界的上下文中显示不少细节，并通过rest api进行编辑。

在此readmodel中处理并发的最佳实践是什么。请参阅以下内容：

1） 如果有一个包含所有相关数据的干净的readmodel，我们可以通过一个请求获得这将是很好的。这就产生了这样的问题：当多个字段可以独立编辑时，我们如何实际创建这个读取模型来保证我们处理所有字段的序列？我们可以添加每个字段的序列号并以某种方式处理，但这会完全混淆我们的readmodel。

2） 我们可以为每个字段提供一个readmodel，使理论上的一切都变得简单，但创建了很多请求，这通常很愚蠢，但易于管理。

3） 我们可以为readmodel创建一个单独的序列表，并以通用序列和每个字段序列的方式进行跟踪，并在必要时使用它来编写新的readmodel。

任何想法。

Answer 1

基于CQRS ES系统的假设是您/用户不直接编辑读取模型。阅读模型是事件流中所有相关事件的结果，即投影。因此，读取模型会因命令而导致的事件而改变。

为了处理该情况下的并发性，我倾向于使用针对读取模型存储的版本号。当你形成一个命令时，它应该包含用来为命令提供上下文的读取模型表的版本。

然后，您可以检查提出的事件是否具有正确的编号。如果不是，你可以抛出一个并发异常。或者您可以创建一个并发解析器服务。这将检查自你的命令问题以来发生的事件是否实际发生冲突。

如果你想知道一个事件源系统更多的并发管理你可以看看这篇文章：

Handling Concurrency Conflicts in a CQRS and Event Sourced System

希望有所帮助。

Answer 2

我们使用严格的事件排序，每个事件中都有一个聚合版本作为元数据。我们也有一个单线程投影。这保证不会有覆盖。

问题出现在这样的系统的可扩展性，到目前为止我们还没有达到这种方法的限制，但一天可能会到来。丹尼尔建议将聚合版本与读取模型一起保存是有道理的，但再一次说明，如果您需要竞争的消费者尝试同时更新模型，则它会在缩放时失败。

正如我们所知，排序是竞争消费者的一个问题，所以我没有真正的现成答案。如果同一字段的并发更新机会将是真实的（而不仅仅是假设），那么我还会考虑字段级读取模型和UI组合。