当Nat Pryce和他的团队开始构建基于事件溯源架构的新系统时，在设计上犯了几个重大的错误，但最后成功地修复了这些错误，修复过程也并不复杂。在一篇博文中，Pryce 详细描述了他们所犯的错误以及促使他们重构架构并从错误中恢复的因素。
他们犯的第一个错误是，将事件历史和对应实体的当前状态视图一起持久化。当前状态不是由于事件更新而产生的投影，而是由记录事件的命令处理程序来更新的。这就引入了两个问题：一是无法通过记录的事件重建实体的状态；二是在将关系模型中管理方式移植过来管理当前状态，开销也十分巨大。
Pryce（《测试驱动的面向对象软件开发》一书的合著者）承认同时使用这两种持久化机制，在某种程度上忽略了事件溯源的整体要点。造成这个错误的原因是，他们提出这个设计为了让团队满意，而没有反思与事件溯源文献中的建议不符之处。他们按照这个设计一直推进到困难明显超过了优势时才反思。随后，通过技术回顾，他们同意转向规范的事件溯源设计。
他们犯的第二个错误是，混淆了事件驱动架构和事件溯源架构。在事件驱动架构中，组件执行任务以响应接收到的事件，并且发出事件来通知状态的变更。在事件溯源架构中，状态变更被当作事件来记录，并且实体的当前状态是根据与实体相关的所有事件计算得出的。对两者的混淆导致产生了这样的设计：对于一个组件来说，既记录了它历史上的所有事件，它又触发了其他组件中的活动。当他们必须在事件中实现相应逻辑以区分，a）读取事件并对其作出反应，和 b）读取事件以了解其历史事件时，他们才意识到了这个错误。
这种混淆也导致了他们将事件存储用作消息总线的设计。消息总线需要发出通知，使组件能够保存最新的投影，这意味着他们使用事件存储来记录事件历史和组件之间的瞬态通信。这使得他们在使用事件存储前，必须从历史中过滤掉的技术事件。
Pryce 描述的最后一个错误是，使用 HTTP 接口在事件存储中读取和存储事件。这阻碍了团队使用ACID事务处理事件，从而迫使他们不得不构建其他机制来试图缓解事务处理的情况。
幸运的是，在线上系统的事件历史受到影响之前，他们早就发现了所有错误。 HTTP 接口已替换成命令处理器的直接数据库连接。他们停止了使用消息通知，转而使用 REST 在组件之间传递数据 。最后，他们去除了命令处理程序中对实体的当前状态的更新逻辑。相反，状态是在加载实体时根据事件历史计算的。他们仍然使用事件当前状态的投影，但这纯粹是为了优化，作为一个直读缓存使用。
Pryce 最后指出，尽管他们对架构进行了重大变更，但这些变更很简单，并且他指出这样做的原因与事件溯源是正交的。
他们的应用程序采用了端口和适配器架构（六边形架构），采用这种架构很容易变更隐藏在端口或适配器接口背后的具体实现。利用端口和适配器架构，还可以编写大量的功能测试。采用该架构，可以实现技术架构与功能实现的分离，这样，技术架构变更时就简单多了。
如 Pryce 所说，当你在系统中采用一种不熟悉的架构风格时，不可避免地会犯错误。他认为，端口与适配器风格不仅允许他们在缺乏经验的情况下采用事件溯源架构，但也可以让他们在构建系统时的误解中恢复过来。
原文链接：
Mistakes and Recoveries When Building an Event Sourcing System
暂无签名
Java 避坑指南：Java 高手笔记代码篇
本迷你书包括 86 个业务开发中常见踩坑点。每一个知识点都相当的实用，是程序员业务开发中的必备避坑指南...
评论