事件采购 – 循环流

在开发新产品时，我做了一个新的（对我来说）发现 – 循环流。它实际上不是一个新概念，但我之前没有碰过这个模式。我想快速描述一下做事件采购的两三个人。 ?循环流是我组成的术语。如果有预先存在的术语，请告诉我。

问题

一些工作流程是循环的：每月审核或每年培训。在过去，我将每个人都表示为自己的事件流。有一个定义的开始和结束，以及介于两者之间的少量事件。这很方便，因为我从未遇到流重放速度慢的情况。然后我不必介绍额外的架构复杂性，如快照（我仍然不需要）。

这种方法存在局限性。有可能在同一时间段内创建重复的流。例如，可以通过用户操作创建一个，而后端进程可以同时创建副本。最终结果是学生两次报名参加相同的培训。这并不是很容易被发现。但是当UI不能自然地表现出重复时，情况会变得更糟，这可能是审计的情况。之前的产品使用了事件和视图存储之间的完全一致性。比赛条件由视图上的唯一索引捕获。但是我们的最新产品最终使用了一致的视图，所以我必须决定如何处理这个角落的情况。

Greg Young有一篇关于集合验证的帖子，它基本上鼓励读者不要过多担心防止重复，而是专注于检测和纠正。因为这不太可能在生产中真正发生。我一般同意这个建议。但是，它仍然需要我编写额外的工具来检测和纠正。更多的东西要注意和维护，即使它比预防选项少工作。我可以设法解决这个问题没有额外的代码吗？

重新思考流

我开始怀疑是否可以在工作流的所有迭代中使用相同的流。例如，特定学生和价格的培训活动总是进入相同的培训流程。我可以使用确定性UUID来计算学生和价格ID的一致ID。 Uuid.deterministic(StudentId + CourseId)。将所有这些单独的流组合成一个大流是一样的。

这可以防止重复，但现在我又回到了需要快照的状态。只有它变得更糟。培训过程可能会随着时间而改变。 （它已经在我们以前的产品中。）因此，快照者必须知道如何处理所有以前的训练过程的特点啊。我们所需要的只是流结束时的当前事件。

等一下……我能不能读一下流的结尾？我记得在玩EventStore时它有一种向后读取流的方法。我总是想知道这可以用于什么，但现在它开始有意义了。我可以向后阅读流，直到我点击标记事件，例如上次训练的最终结果： TrainingCompleted （要么 Canceled 管他呢）。我认为就是这样

总而言之，这种模式的成分如下。

• 循环过程，例如年度培训
• 基于所涉及实体的ID的一致ID
  • 小心使用可以改变的“自然键”
• 向后读取流直到标记事件以获取“当前”事件

这巧妙地避免了创建重复流的可能性。它也不需要额外的建筑作品。代码我没有写（特别是建筑）是我的最爱。

/∞