事件溯源的价值

作者｜Keith Mifsud

译者｜Erica Yi

编辑｜Emily

我真的觉得有必要写下这篇文章，因为我觉得大多数的开发人员认为事件溯源（Event Sourcing）只是另一种的 PoEAA（企业应用架构模式，Pattern of Enterprise Application Architecture）。或许会只用于有一定复杂程度的软件模型上，或者至少看起来需要的软件模型上，以便证明需要的时间和费用。但我想说的是，事件追溯不仅仅是一种构架选择，它最大的价值在于它所保存的数据。

什么是事件追溯？

如前所述，本质上，我们大多数人认为事件追溯只是企业应用程序开发的一种模式。我不同意这种说法，至少单独就事件追溯而言，它不是一种模式。事件溯源能够被应用在，而且已经被应用在了不同类型的程序、企业和其他领域。我们手机上的通话记录跟在 CRM（客户关系管理，Customer Relations Management）应用程序中大多数客户交易一样，始终保持为事件。

正如 Martin Fowler 在一篇文章的序言中所说的，事件溯源——“将一个应用程序状态的所有变化捕获为一系列事件”。从这个描述中，我们可以提取出事件溯源的真实价值，也就是我认为的以事件形式收集到的数据。我发现人类其实会自然地从一系列的事件中梳理出逻辑，因为我们的生活本身就是由一系列的事件构成的。我们的行为、思想、事件、工作、梦想以及其他所有的事情都是一种事件。当一些事情发生时，就是一个事件。既然我们如此熟悉以事件形式收集到的数据，那为什么我们不能保留这种信息收集的方式呢？

为什么事件溯源如此的重要？

数据是我们这个时代最宝贵的资源之一。数据对于大多数行业来说是不可或缺的。数据被收集、出售和购买，被用于交换和谈判。但是当数据以事件的形式出现时，甚至更有价值，因为不同于简单的邮件列表（顺便说一句，快来订阅），由事件溯源得到的数据充满了我们甚至不知道的我们会需要的信息，但我们可以放心地假设，里面一定有我们将会需要的。从存储的事件中，我们可以提取行为、模式、习惯等等。

在事件发生后应该储存其导致的事实，而不是把这些信息扔掉。因为即使在当前，也有应用程序在使用这些信息。在将来的话，则可能会有更多的应用程序需要这些信息。

什么时候需要应用事件溯源？

事件溯源可以被应用在有事件发生的任何领域（domain），从咖啡机中的 IC（集成电路）到 ERP（企业资源规划，Enterprise Resource Planning）系统的任何事情。如果事情（事件）发生，那么你可以存储这个事实。

这是否意味着我们应该将事件溯源应用到每个应用程序中？简单来讲的话，我们确实应该这样做。更长的答案是，只要你负担得起，你都应该应用事件溯源。反过来想可能更清楚，我们什么时候不应采用事件溯源？答案更简单。当你承担得起应用程序本应存储但却正在丢失的数据时，不要应用事件溯源。今天没有储存的东西明天就无法使用，而我相信明天你将需要所有的东西。

我相信事件溯源尚未得到充分地利用的主要原因有两点。一是缺乏如何将其应用于综合系统的知识，二是应用这种模式所涉及到额外的工作。这两个原因均没有衡量信息丢失的情况，但是两者都很容易得到缓解。有关于如何应用于综合系统的知识是现有的，而且大部分涉及到的额外工作，都可以通过使用代码文件生成器和采用基础构架框架来减少和消除。即使你自己需要自行创建相关的生成器和框架，它们也会被一遍又一遍地重复利用，而且大部分的时候，都只用构建一次。

规划和应用事件溯源相对来说比较简单。在我看来，事件溯源中的 domain model 的建立远比一个领域驱动设计（Domain Driven Design，缩写 DDD）本身，更不用说数据驱动设计（Data Driven Design ）简单多了。原因是如果我们以事件的形式来思考给出的问题，那么呈现的情况会很接近于我们实际生活的情况。透过现实生活来思考软件，会比用算法或者其他处理逻辑来得简单。

机器学习和事件溯源

让我们先暂时忽略 Alphabet 和 Facebook 那些做大数据的人，想下我们如何可以从事件溯源获得的数据中获益。我第一个能想到的应用是机器学习，它有一个主要的要求就是数据。

在上面我们已经讨论过了，由事件溯源得到的数据比其他任何可能从方面（context）得到的数据都要有价值的多。还有一个事实是，机器学习试图，并且大多数情况下都成功地构建了算法，并基于数据做出预测。在精心策划的事件溯源模型（event sourced model）中捕获到的数据，复制了人类或任何实体所遵循的真实过程。将这些准确的数据提供给机器学习算法，将会产生非常有用的预测。

我们甚至不需要想象与之相对应的应用场景，因为已经有很多应用场景了，但是将往深的在想几步，将每个输入设备都连接到一个 event store，之后预测的结果又可以被无数的机器思考应用，比如健康和心理诊断应用所使用。将你最喜欢的 IDE 连接到一个 event store，你甚至可能会得到自动开发软件的应用程序。

机器学习事实上是相当基础的，但却非常准确和强大。将机器学习用于事件溯源数据建模，唯一缺少的一块就是我们通过使用软件模型和持久性架构每天扔掉的数据。这些浪费掉的信息导致了几项突破性创新的推迟，以及治疗和整体生活改善上的滞后。

在我写这篇文章的时候，YouTube 是自动播放音乐的，而且出于某些原因，它正在播放一些令人放松的 Jazz＆Bossa Nova。要我自己选的话，我永远不会选这类的音乐。但是，此时这类音乐跟我手头做的东西完全吻合。我很欣赏 Youtube 帮我选的音乐。这个 Youtube 的音乐机器主要负责音乐的挑选，但是，我敢肯定，我们将可以找到更多有用的机器学习的应用程序。从现在开始，让我们开始保留事件溯源的数据，因为可能明天，下周或明年某人（或某事，强烈暗示艾隆·马斯克）就将会大量使用这些它们。

人工智能并没有那么人工的

我真的从来都不喜欢“人工智能”这个词。举个例子，如果将人工的这个词用在“自动驾驶汽车”上会怎样呢？汽车是物理的，它由其本身驱动，换句话说，它是物理的而不是人工的从不同的能源产生动能，并且用一个软件应用沿着特定的路线将其引导到目的地。

就在几年前，我们会将语音识别称为人工智能，这在当时是有道理的，因为那些非常蠢并且令人讨厌的 IVR（交互式语音应，Interactive Voice Response）系统提供的帮助和支持是人造的。现在，我们很多人用语音识别的时候，甚至没有在想它是语音识别。我在电话的麦克风上发出“Okay Google”，多过于我在任何一天给真实的人说“Hi”的次数。我不认为这种技术是人工智能，很可能你也不会这样认为。我认为共识是，当机器学习项目仍在其蓬勃发展的时期，我们将其称为人工智能，但当其成为我们生活中的一部分的时候，那时它就是智能了。

基于捕获到事件数据的机器思考应用机器，根本就不是人工的。我的意思是，就比如 CIA（中央情报局）每天都在使用机器学习算法， 那我们应该把它叫做 CAIA（中央人工智能局）吗？

最后的一些想法

我想在本文中传达的主要观点是：

1）事件溯源是非常重要的，不仅仅是为了便于对领域（domain）进行建模，而甚至更加在于它捕捉到的数据。

2）事件溯源是一种达到目的的手段，而这个目的在于机器学习。

3）基于捕获的事件流的机器思考应用，绝对不是人工智能。它是基于现实的，而不是人工的。

最后我想说……

如果您觉得内容不错，记得给我们「留言」和「点赞」，给编辑鼓励一下！