transactions - 事件溯源中的事务处理

Question

我正试图围绕事件溯源中的事务处理。

我的事件存储中有一个聚合(事务范围)。

一个命令得到处理并产生 10 个事件。现在，这可以作为 1 笔交易处理还是 10 笔交易？对于事务，我的意思是对仅作为一个整体有效的状态的更改。即使我希望将它们作为一个整体处理，但如果它们被拆分成许多这样的事件，我是否设计错了？

我倾向于认为是命令定义了事务、意图，并且该命令产生的所有事件都应该作为一个整体来处理。这意味着它们应该只作为一个整体被持久化，作为一个整体加载，对读者作为一个整体(原子地)可见，并且也只能作为一个整体发送给我的事件总线上的监听器。

这是正确的想法吗？

这在例如 Kafka 和 Event Store 中是如何处理的？

那么产生许多事件的命令呢，这真的是很好的设计吗？我想要一些事情发生(命令)并且发生了一些事情(事件)，没有发生很多事情？我希望有这种 1:1 的关系，但我在这里和那里读到命令应该能够产生许多事件，但为什么呢？

对不起，我希望有人能在这里得到我想问的问题。

Answer 1

A command gets processed and is producing 10 events. Now, can this be handled as 1 transaction or is this 10 transactions?

作为写入，这通常被建模为单个事务；要么整个​​commit被添加到历史记录中，或者什么都没有。

that they should only be persisted as a whole, loaded as a whole, visible to readers as a whole (atomically) and also only sent to listeners on my event bus as a whole.

read 方面可能有点棘手。毕竟，事件只是事件；作为消费者，我什至可能对它们都不感兴趣，尽快消费它们而不是等待一切都按顺序出现可能具有商业值(value)。

对于排序很重要的消费者，在这些情况下，您将读取流，而不是事件。但仍然存在这样的情况，即您可能在消费者中存在批处理/分页问题，​​这与将所有工作对齐提交边界的目标相冲突。

要记住的是，从读者的角度来看，没有不变量需要维护。事件流只是发生的一系列事情。

唯一真正关键的情况是编写者试图加载聚合状态；在这种情况下，您需要整个流，而提交边界基本上是无关紧要的。

How is this handled in for instance Kafka and Event Store?

在 Greg Young 的事件商店中，writing to a stream意味着将有序的事件集合复制到流中的指定位置。整个区 block 进来，或者根本不进来。

Reading from a stream包括分页支持——允许客户端请求一系列位于提交边界之间的事件。该文档不保证在这种情况下会发生什么。碰巧的是，返回的表示可以支持返回比可用事件更少的事件，因此事件可能总是在提交边界上返回。

我的阅读理解the source code是用于将流存储在磁盘上的持久性结构不会尝试保留提交边界 - 但我在这一点上肯定会弄错。

I'd like to have this 1:1-relationship but I read here and there that commands should be able to produce many events, but why?

有几个原因。

首先，聚合是人工的；它们是我们用来确保日志中数据完整性的一致性边界。但是一个给定的聚合可以组成许多实体(例如，在低争用级别下，将整个域模型放入一个“聚合”中并没有本质上的错误)，并且将不同实体的更改视为彼此不同通常很有用. (替代方法类似于每次都编写 SomethingChanged 事件，并坚持让所有客户端都使用该事件以了解发生了什么)。

其次，重新建立域不变量通常是与命令中指定的操作分开的操作。 Bob 只是从他的账户中提取了比他可用的更多的现金；我们需要更新他的帐户分类帐并将问题上报给人类。哦，这是一个描述 Bob 当天早些时候存款的新命令，我们需要更新他的账户分类帐并告诉人们停止。

但从广义上讲，因为区分命令的多重后果更符合业务的自然语言。