大多数学习事件溯源的人都是将其作为应用程序设计模式，当然这是事实。但是，使用事件溯源的主要原因是该模式激活了事件数据模型。
我很早在80年代中期关系型数据开始兴起时就在关系型数据库领域工作。关系数据库采用的一个主要推动力是关系（相对于层次结构）不需要您锁定查询访问模式。
当业务需求发生变化时，关系型模型提供了保证，您可以通过原始设计中未曾预期设计的方式查询数据。首席技术官，架构师，开发人员甚至首席执行官都得到了信息，大多数人都知道企业的成败取决于其应对变化的能力。
事件数据模型（底层的事件存储和事件源）使我想起了关系引发的思想上的同一类型的变化。事件数据模型又向前迈进入了一个更基本的核心数据模型组件。
事件数据模型将状态的更改作为基本数据模型，然后允许您“投影”到需要在查询端利用该数据的任何其他数据模型，可以是关系型，文档型，图形型（随您命名）。当业务需求更改时，您可以更改或重新生成查询模型以满足您的需求。
关系数据模型及其所有功能都是有损失的。它捕获的数据可证明虽是可查询的，但是它的重点是保持数据的当前状态。删除和更新后就丢失原来数据..一旦数据消失，就无法查询。
关系数据模型基础状态的更改“折叠”为特定的当前状态数据模型，该模型灵活但并未针对查询或写入进行特别优化。
关系型“标准化”数据模型会将逻辑业务实体分解为多个表，必须将它们同时写入并从中读取以获取数据……正如我们中许多人所知道的，当需要常见查询时会进行10个多表联接join。
事件存储和事件数据模型代表着关注点的分离，事件存储专注于优化仅将事件流追加并“实时”提供给那些最适合您的用例的查询引擎。
事件存储数据库和事件数据模型在某些方面看似新颖且具有革命性，但它们仍在不断发展。大多数数据库技术以及分布式共识算法都将“日志 log”作为其基础数据结构。
事件存储将这种日志打开开放，并建议将其作为数据库本身。
事件数据模型日趋成熟的一个标志是事件数据设计方法论从分析到实施（事件风暴，事件建模等）的出现。
从另外一个方面看，事件数据模型在db级别实现的基础事件往往与设计工件同构。换句话说，数据库中的事件往往代表业务可理解的事件和语言。这可能会产生深远的影响，您的系统监视也将是对业务监视。
事件存储有潜力成为下一代可操作的“真相之源”，事务性数据库技术。它们具有一流的流API的无损特性，使它们处于多种宏观趋势的汇合处，例如（微）服务，强大的分析和集成技术的爆炸式增长，区块链和AI。
事件源作为应用程序开发模式是用于构建现代系统（尤其是分布式异步系统）的强大工具。这是一个重要的考虑因素，会让您决定选择事件来源模式。但是，还有一个强有力的考虑因素，可以说是最重要的，它是基础数据的价值和事件数据模型本身。
banq注：eventsourcing = domanEvents + eventstorming + eventModel + blockchainData + dataScience！
相关：
由亚马逊内部禁止使用SQL数据库引出的想法
arxiv文献：事件溯源系统及其图式演变的经验表征-行业经验教训