我试图围绕事件采购中的交易。
我的事件存储中有一个聚合（事务范围）。
命令被处理并产生10个事件。现在，这可以作为1个交易处理还是这10笔交易？对于交易，我的意思是改变只能作为一个整体有效的状态。如果将事件分成很多类似的事件，即使我希望将它们作为一个整体处理，我是否设计了错误的事件？
我倾向于认为这是命令，它定义了事务，意图，并且该命令产生的所有事件应该作为一个整体来处理。这意味着它们应该只作为一个整体保存，作为一个整体加载，作为一个整体（原子）可以被读者看到，也只能作为一个整体发送给我的事件总线上的听众。
这是正确的想法吗？
如何处理例如Kafka和Event Store？
那些产生很多事件的命令呢，那真是好的设计吗？我想要发生一些事情（命令）和发生的事情（事件），发生了很多事情？我希望有这种1：1关系，但我在这里和那里读到命令应该能够产生很多事件，但为什么呢？
对不起，我希望有人能得到我在这里要问的内容。
答案 0 :(得分：5)
命令被处理并产生10个事件。现在，这可以作为1个交易处理还是这10个交易？
作为写入，这通常被建模为单个事务;将整个commit添加到历史记录中，或者没有任何内容。
它们应该只作为一个整体保存，作为一个整体加载，作为一个整体（原子）可以被读者看到，也只能作为一个整体发送给我的事件总线上的听众。
read 方面的事情可能有点棘手。毕竟，事件只是事件;作为一个消费者，我甚至可能对它们都不感兴趣，尽可能快地消费它们可能具有商业价值，而不是等待一切按顺序出现。
对于排序很重要的消费者，在这些情况下，您将阅读流而不是事件。但仍然存在这样的情况：您可能在消费者中遇到与在提交边界上对齐所有工作的目标相冲突的批处理/分页问题。
要记住的一点是，从读者的角度来看，没有不变量可以维护。事件流只是发生的一系列事情。
唯一真正关键的案例是作家，试图加载聚合状态;在这种情况下，您需要整个流，并且提交边界基本上是无关紧要的。
如何处理例如Kafka和Event Store？
在Greg Young的事件存储中，writing to a stream表示将有序的事件集合复制到流中的指定位置。整块都进来了，或者根本没有。
Reading from a stream包括分页支持 - 允许客户端请求落在提交边界之间的一系列事件。该文档不保证在这种情况下会发生什么。碰巧，返回的表示可以支持返回比可用事件少的事件，因此可能总是在提交边界上返回事件。
我从阅读the source code的理解是，用于在磁盘上存储流的持久性结构不会尝试保留提交边界 - 但我在这一点上肯定会弄错。
我希望有这种1：1关系，但我在这里和那里读到命令应该能够产生很多事件，但为什么呢？
有几个原因。
首先，聚合是人为的;它们是我们用于确保期刊中数据完整性的一致性边界。但是，给定的聚合可以组成许多实体（例如，在低争用级别，将整个域模型放入单个“聚合”中没有任何内在错误），将不同实体的更改视为彼此不同通常很有用。 。 （替代方法类似于每次都写一个 SomethingChanged 事件，并坚持所有客户都使用该事件来查明发生的事情。）
其次，重新建立域不变量通常是与命令中指定的操作分开的操作。鲍勃刚刚从他的帐户中提取了更多的现金;我们需要更新他的帐户分类帐和将问题升级为人类。哦，这是一个新的命令，描述了鲍勃在当天早些时候做出的存款，我们需要更新他的帐户分类帐和告诉人类站起来。
但从广义上讲，因为区分命令的多重后果会更好地与业务的自然语言保持一致。