定义应用程序的架构三步：
1、定义系统操作
2、定义服务
3、定义服务API和协作方式
一、识别系统操作
起点：需求（包括用户故事及其相关的用户场景）
步骤：
1、创建由关键类组成的抽象领域模型（关键类提供用于描述系统操作的词汇表）
2、确定系统操作，并根据领域模型描述每个系统操作的行为。
领域模型主要源自：用户故事中提到的名词。
系统操作主要来自：用户故事中提到的动词。
系统操作类型：
1、命令型：创建、更新、删除数据
2、查询型：查询和读取数据
二、定义微服务架构
2.1 服务拆分
策略一：根据业务能力进行服务拆分（前提：业务稳定）
策略二：根据子域进行服务拆分
DDD：领域驱动设计；其特别重要的两个概念：子域和限界上下文。
领域为每个子域定义单独的领域模型。子域是领域的一部分，领域是DDD中用来描述应用程序问题域的一个术语。
识别子域的方法：分析业务并识别业务的不同专业领域【和识别业务能力方式一样，结果也接近】
限界上下文：领域模型的边界。它包括：实现模型的代码集合。
当使用微服务架构时，每个限界上下文对应一个或一组服务。
总结：微服务架构设计工作--通过DDD方式定义子域，把子域对应为每个服务。
2.2 拆分指导原则（源于面向对象设计）
原则一：定义类的职责，遵循单一职责原则
软件架构和设计的主要目的之一是确定每个软件元素的职责。
单一职责原则：改变一个类应该只有一个理由。---Robert C.Martin
遵循SRP原则，所定义的每一个类都应该只有一个职责。
设计微服务架构时应遵循SRP原则，设计小的、内聚的、仅仅含有单一职责的服务，这会缩小服务的大小并提升它的稳定性。
原则二：类组成包，遵循闭包原则（CCP）
闭包原则：
在包中包含的所有类应该是对同类的变化的一个集合。也就是说，如果对包作出修改，需要调整的类应该都在这个包之内。
----Robert C.Martin
如果由于某些原因，两个类的修改必须耦合先后发生，那么就应该把它们放在同一个包内。这样做的目的是，当业务规则发生变化时，开发者只需要对一个交付包做出修改，而不是大规模修改（和重新编译）整个应用。
采用闭包原则，可以极大改善应用程序的可维护性。
CCP是解决分布式单体的法宝。
2.3 服务的分解障碍
1、网络延迟（因为服务之间的网络往返太多）
解决方案：
第一种：批处理API在一次往返过程中获取多个对象，从而将延迟减少到可接受的数量
第二种：把多个相关往返的服务组合在一起，用编程语言的函数代替昂贵的进程间通信。
2、服务之间的同步通信降低了可用性
解决方案：异步
3、需要维护跨服务的数据一致性。（需要使用Saga）
Saga：一系列使用消息协作的本地事务。Saga的一个限制是：它们最终是一致的。
如果需要以原子方式更新某些数据，那么它必须位于单个服务中，这可能是分解的障碍。
4、获取一致的数据视图（无法跨多个数据库获得真正一致的数据视图）
在微服务架构中，即使每个服务的数据库一致，也无法获得全局一致的数据视图。
如果需要一些数据的一致视图，那么它必须驻留在单个服务中。
5、上帝类（God Class）（可以使用领域驱动设计的概念消除）
上帝类：在整个应用程序中使用的全局类。通常为应用程序的许多不同方面实现业务逻辑，它有大量字段映射到具有许多列的数据库表。
上帝类将应用程序的许多方面的状态和行为捆绑在一起。
三、定义服务API
服务API：服务的操作和事件。
存在服务API操作的原因：
1、某些操作对应于系统操作。由外部客户端调用，也可能由其他服务调用。
2、存在一些其他操作用以支持服务之间的协作，这些操作仅由其他服务调用。
定义服务API的步骤：
1、将每个系统操作映射到服务；
分配方式：
1、将操作分配给需要操作所提供信息的服务；
2、将操作分配给具有处理它所需信息的服务
2、确定服务是否需要与其他服务协作以实现系统操作；
3、如果需要协作：确定其他服务必须提供哪些API才能支持协作。
笔记来自：《微服务架构设计模式》一书，作者 [美] 克里斯·理查森 著，喻勇译