.net core 如何验证DDD-事件源中的事件流？

我正在构建DDD/CQRS事件源应用程序。（.NET、EventStore）

我读了很多关于它的文章，尤其是著名的银行账户话题

作为提醒，我们有以下事件顺序：

创建银行账户

存放

撤回

变换器

存放

但是我从来没有找到一篇解释如何验证事件序列的博文？ 我的意思是，如果我在BankAccount创建之前先收到存款事件，会发生什么？ 换句话说，如何检查是否创建了银行帐户？ 如何知道流处于有效状态

我必须调用read模型吗？每一次？在每个事件中？聚合的每种方法？ 如果用户发送了两次，而readmodel尚未同步，会发生什么情况

我已经阅读了很多关于事件源的资料，可能还不够^^^，但是我没有找到任何关于事件流一致性的信息

在我的应用程序中，如果“第一个”事件（ContactAdded）不存在，我无法应用事件。 这是否意味着每次我需要做某事时都要打电话给EventStore

谢谢你的帮助。

那里有很多

如何知道流处于有效状态

每个流在每个事件上都应该有一个单调递增的版本号。每个流（聚合）的事件1应先于事件2等。EventStore将通过应用乐观并发来确保此级别的一致性。在将事件写入事件存储时，可以提供预期的流版本（例如，上次写入的版本）。当您读取事件流时，会获取最后的版本号，并在将事件写入EventStore时传递该版本号。如果自上次读取后事件流已增长，则会引发并发错误

我必须调用read模型吗？每一次？在每个事件中？聚合的每种方法

这里的术语有些混乱。记住事件与命令、读模型与写模型，以及每个模型的用途。显示读取模型中的数据。您可以根据编写模型进行验证和处理

如果用户发送了两次，而readmodel尚未同步，会发生什么情况

考虑到上面的乐观并发策略，您基本上获得了wins策略中的第一个。为了克服这个问题，您可以捕获并发错误并从头重新处理命令（从EventStore获取最新状态）

这是否意味着每次我需要做某事时都要打电话给EventStore

对。在每个命令上，您将读取聚合和还原状态的事件流。您可以将快照用作优化，但其概念保持不变

如何验证DDD-事件源中的事件流？ 如何知道流处于有效状态

在域驱动设计中，域模型有责任确保状态满足域不变量。你可以把它看作一个函数

everythingWeKnowNow = domainModel(everythingWeKnewBefore, newInformation)

随着新信息的到来，我们将其与之前发生的事情结合起来，以产生新版本的“真相”

在CQRS的世界里，这一切都发生在“写模型”中——我们从“真相”的权威表示开始工作，而不是过时的副本，我们根据域的要求修改它

事件源部分实际上只是表示的一个区别：我们不计算新状态，然后覆盖以前的副本，而是计算更改，并将这些更改附加到以前的副本中（我们总是可以通过简单地枚举更改列表来重新计算状态）

因此，我们的状态的权威副本总是包含由域模型按照写入顺序计算的事件

这里的广义模式是这样一种想法，即模型是系统中信息的权威，而事件源只是存储该信息的另一种方式（支持时态查询的方式）

对于解决方案中需要对事件进行权威排序的部分，诀窍是将它们作为有序序列从事件存储中检索，而不是一次读取一个并尝试重新构建序列。换句话说，您将使用拉模型而不是推模型来将事件从一个系统传递到另一个系统

当您在基于推送模型的系统中工作时，事件可能会被错误排序，那么您需要将其构建到您的设计中。这往往以跟踪丢失的信息并等待信息到达的形式发生

（您还必须更加注意时间；消息到达时间是了解事情发生时间的一个相当有损的替代品）

---

分布式系统很难实现，我们在本地学习到的捷径不再有效。

谢谢你的回答，这证实了我最初的想法。