顶级架构是指如何部署多个组件并相互通信。例如,这个架构可能是EDA(事件驱动架构)或SOA(面向服务的架构)。事件溯源则不是这样的。相反,事件溯源是一种应用程序架构模式,并且与任何其他设计模式一样,它通过一种良好的记录方法来解决特定的常见问题。
将事件溯源应用于整个系统实际上被认为是反模式。这是一种在内部创建事件溯源的大型单体monolith方法。
它不是框架我们不构建事件溯源框架,我们不应为任何其他设计模式构建框架。
尽管如此,事件溯源意味着持久性,事件存储可以是一个有助于应用该模式的隔离系统,但它不是模式本身。常用存储系统的示例是Event Store和Apache Kafka。
它不是CQRS事件溯源和CQRS(命令查询责任分离)已经被应用在一起几年了,但它们是不同的模式。
Bertrand Meyer在1988年的“面向对象软件构造”一书中,CQRS最初被记录为CQS(命令查询分离),并且从那时起已被应用了很多。
将状态建模为事件,很自然需要不同的读取方式,因为不能直接读取状态了,必须把事件转为状态。客户不想收到一连串的操作事件。相反,他们希望对他们期望的信息保持一致的状态。针对某些类型的查询或跨越多个有界的上下文,我们可以实现另外一种适合读取的存储方式(高速缓存,物化视图等)。
它不是异步或最终一致它与最终的一致性无关。前面上述脚本正在存储事件,每个读取可以正在抓取所有事件以显示最新状态。
我们也可以异步地做这些,我可以通过后台任务读取事件和更新其他地方的状态,并改变读取路径。这将使其最终保持一致。但是我们不必这样做。
世界上最流行的事件溯源应用是Git。Git是完全同步的,并且具有作为事件溯源的所有优点,例如在时间上进行时间查询或及时来回地在不同的时间点中挑选代码以及其他用例。
它不存储发生的一切除非事件非常少量或有足够的存储空间,否则状态并不是由每一个曾经存在的事件构成的。与事件溯源相关的是执行快照或压缩的概念,从什么时候开始播放事件变得很重要,因此重视“时间的开始”更为现实。
从此得出结论?事件溯源通常被错误地与EDA(事件驱动架构)相关联。事件溯源是一种应用程序架构模式,它允许更好的审计,提供状态重播或迁移动到特定时间点的能力,它自然地提高了写方面的性能改进,因为将事件追加(不是修改)到持久存储中真的很快。
采集整个系统的事件是一个很大的错误,被认为是一种反模式。它本身不是架构,它不会使应用程序更好地通信,它只是通过存储发生的事实而不是存储当前视图,使单个应用程序更加一致和可审计。
这很像当我丢失了车钥匙,只能在我的头脑中重播所有刚发生的事情,并且我同步地和一致地做这些事情,直到我再次找到它,否则我需要乘坐公共汽车。
What Event Sourcing is not
来源: http://www.jdon.com/blog/banq