从事件和DDD入手来构建微服务

by Jan Stenberg on Dec 28, 2016

摘要：

领域驱动设计（Domain-Driven Design，DDD）是一项很伟大的技术，它拉近了设计与程序实际所服务的领域，但是通常我们会关注结构，从而太早地做出决策，这并非DDD的本意。相反，在领域中，我们应该从事件开始，Russ Miles描述了在构建微服务时，采用“事件优先”的方式所具有的优势。

领域驱动设计（Domain-Driven Design，DDD）是一项很伟大的技术，它拉近了设计与程序实际所服务的领域，但是通常我们会关注结构，从而太早地做出决策，这并非DDD的本意。相反，在领域中，我们应该从事件开始，Russ Miles描述了在构建微服务时，采用“事件优先”的方式所具有的优势。

Miles认为除了关注结构之外，我们还过多地关注了通用语言（ubiquitous language），尤其是在领域对象方面更是如此。更糟糕的是，我们还会着手创建一些跨领域边界重用的库，这些库中包含了领域对象，这实际上阻碍了不同边界上下文（bounded context）的独立演化。

在Miles的经验中，对于企业级分层架构来说，这种方式已经成为了默认的架构风格，这么做的原因在于它能够让事情变得更容易，而不是更简洁或者有助于提升设计。这样做会带来一定的问题，比如实体变成了通用的，从只位于某个上下文之中变成了跨所有上下文的规范，这是与DDD的理念背道而驰的。

与上面提到的做法不同，Miles宣称我们首先要从领域中发生了什么入手，也就是事件。在领域中，它们能够更好地捕获通用语言，通常也是描述领域的最简单的方式，尤其是在跟领域专家合作的时候更是如此。他发现无论是构建新的系统还是演化已有的系统，这种方式都非常适用。

Miles主张在使用事件时，第一步是事件风暴（Event Storming），这是由Alberto Brandolini所创建的一项建模工作坊技术。其基本理念就是通过领域中所发生的事情（也就是领域事件）来探索这个领域，并且使用便签来描述领域中的事件，这些便签会沿着时间轴贴到一个很大的建模面板上。举例来说，能够引发事件的事情包括用户行为、外部系统所发生的事情以及时间的流逝。事件也有助于找到领域的边界，对术语的不同阐述可能就意味着存在边界。

对Miles来说，另外一个导致复杂性的地方在于为错误的工作任务使用错误的模型。针对状态的持久化，DDD提供了repository模式，通常的做法是在读取和写入方面，使用相同的模型。这种方式带来的一个好处就是一致性，但是如果需求稍微有所差别，那么将读取和写入通过不同的模型进行分离将会取得明显的收益。

命令查询职责分离（Command Query Responsibility Segregation，CQRS）就是一种实现这种分离的技术：

• 命令作用于写入模型上，并且要以一致的方式进行修改，最好是在一个聚集（aggregate）上，它会产生一个或多个事件。Miles指出所创建出来的事件并不是副产品，它们是命令的实际结果。
• 查询使用一个或多个读取模型，针对查询会进行一些优化。写入模型所生成的事件会被读取模型接受到，读取模型会进行更新，从而反映写入模型的状态。

事件溯源（Event sourcing）是对CQRS的自然扩展，在这里聚集产生的所有事件都会进行持久化，可以用来重新创建聚集的状态，而不是存储状态本身。按照Miles的说法，这种能力可以重建状态，是一种降低状态脆弱性的方法。

CQRS以及事件溯源会带来其他的复杂性，比如最终一致性（eventual consistency）;Greg Young是CQRS这个术语的创造者，他也对如今的事件溯源很感兴趣，他认为这两者都不是顶层的结构（top-level architecture）。按照Young的说法，它们只能有选择地应用于某些地方，他强调整个系统都基于事件溯源构建是一种反模式。

查看英文原文：Start with Events and DDD When Building Microservices