如何定义一个微服务架构呢？跟所有的软件开发过程一样，一开始我们需要拿到领域专家或者现有应用的需求文档。跟所有的软件开发一样，定义架构也是一项艺术而非技术。本文我们将介绍一种定义应用程序架构的三步式流程，如图1所示。世界上并没有一个机械化的流程可以遵循，然后指望这个流程输出一个合理的架构。我们只能介绍一个大概的方法，现实世界中，这是一个不断迭代和持续创新的过程。
图1 用于定义应用程序的微服务架构的三步式流程
应用程序是用来处理客户端请求的，因此定义其架构的第一步是将应用程序的需求提炼为各种关键请求。但是，不是根据特定的进程间通信技术（如REST或消息）来描述这些请求，而是使用更抽象的系统操作这个概念。系统操作（systemoperation）是应用程序必须处理的请求的一种抽象描述。它既可以是更新数据的命令，也可以是检索数据的查询。每个命令的行为都是根据抽象领域模型定义的，抽象领域模型也是从需求中派生出来的。系统操作是描述服务之间协作方式的架构场景。
该流程的第二步是确定如何分解服务。有几种策略可供选择。一种源于业务架构学派的策略是定义与业务能力相对应的服务。另一种策略是围绕领域驱动设计的子域来分解和设计服务。但这些策略的最终结果都是围绕业务概念而非技术概念分解和设计的服务。
定义应用程序架构的第三步是确定每个服务的API。为此，你将第一步中标识的每个系统操作分配给服务。服务可以完全独立地实现操作。或者，它可能需要与其他服务协作。在这种情况下，你可以确定服务的协作方式，这通常需要服务来支持其他操作。你还需要确定选用第3章中描述的哪种进程间通信机制来实现每个服务的API。
服务的分解有几个障碍需要克服。首先是网络延迟。你可能会发现，由于服务之间的网络往返太多，特定的分解将是不切实际的。分解的另一个障碍是服务之间的同步通信降低了可用性。你可能需要使用第3章中描述的自包含服务的概念。第三个障碍是需要维护跨服务的数据一致性。你需要使用第4章中讨论的Saga。分解的第四个也是最后一个障碍是所谓的上帝类（God Class），它广泛应用在整个应用程序中。幸运的是，你可以使用领域驱动设计中的概念来消除上帝类。
本节首先介绍如何识别应用程序的系统操作。之后，会研究将应用程序分解为服务的策略和指南、分解的障碍以及如何解决它们。最后，将描述如何定义每个服务的API。
1 识别系统操作
定义应用程序架构的第一步是定义系统操作。起点是应用程序的需求，包括用户故事及其相关的用户场景（请注意，这些与架构场景不同）。使用图2-6中所示的两步式流程识别和定义系统操作。这个流程的灵感来自Craig Larman的名著《Applying UML and Patterns》中介绍的面向对象设计过程。第一步创建由关键类组成的抽象领域模型，这些关键类提供用于描述系统操作的词汇表。第二步确定系统操作，并根据领域模型描述每个系统操作的行为。
图2 使用这个两步式流程从应用程序的需求识别系统操作。第一步是创建一个抽象领域模型。第二步是定义系统操作，这些操作是根据领域模型定义的
领域模型主要源自用户故事中提及的名词，系统操作主要来自用户故事中提及的动词。你还可以使用名为事件风暴（Event Storming）的技术定义领域模型，我将在第5章中讨论。每个系统操作的行为都是根据它对一个或多个领域对象的影响以及它们之间的关系来描述的。
系统操作可以创建、更新或删除领域对象，以及创建或破坏它们之间的关系。
我们来看看如何定义抽象领域模型。之后，我将根据领域模型定义系统操作。
创建抽象领域模型
定义系统操作的第一步是为这个应用程序描绘一个抽象的领域模型。注意这个模型比我们最终要实现的简单很多。应用程序本身并不需要一个领域模型，因为我们在稍后会学到，每一个服务都有它自己的领域模型。尽管非常简单，抽象的领域模型仍旧有助于在开始阶段提供帮助，因为它定义了描述系统操作行为的一些词语。
创建领域模型会采用一些标准的技术，例如通过与领域专家沟通后，分析用户故事和场景中频繁出现的名词。例如Place Order用户故事，我们可以把它分解为多个用户场景，例如这个：
