如何定义一个微服务架构
定义一个应用程序的微服务架构分为三步式流程，注意这些只是一个大概的方法。
- 第一步，定义系统操作。系统操作指的是应用程序必须处理的请求的一种抽象描述，所以这一步就是将需求提炼为各种关键请求。
- 第二步，定义服务。就是如何分解服务。
- 第三步，定义服务 API 和协作方式。确定每一个服务的 API，将第一步中标识的系统操作分配给服务，服务可以独立的实现操作，也可能需要与其他服务进行写作。
定义系统操作
定义系统操作有两个步骤：
- 第一步，创建由抽象类组成的抽象领域模型，领域模型主要源自于需求中所提及的名词。
- 第二部，确定系统操作，系统操作主要源自于需求中所提及的动词。有两类系统操作：
- 命令型：创建、更新或者删除数据的系统操作。
- 查询型：查询和读取数据的系统操作。
抽象的领域模型和系统操作能够回答这个应用做什么这一问题。
定义服务（服务拆分）
在定义完系统操作后，下一步要做的就是进行服务的识别。有多种拆分策略可以选择。
根据业务能力进行服务拆分
组织的业务能力指的是这个组织的业务是做什么，它们通常都是稳定的。而采用何种方式实现业务能力，是不断变化着的。
一旦识别出业务能力，就可以为每一个能力或者能力组（这部分是非常主观的）定义服务。一个例子如下，为一个送餐应用定义的服务：
根据子域进行服务拆分
根据子域进行服务拆分就是根据 DDD 的子域设计服务。
DDD（领域驱动设计）为每一个子域定义单独的领域模型，识别子域跟识别业务能力一样所以结果也非常接近。可以通过 DDD 的方式定义子域，并把子域对应位一个服务，这样就完成了服务的拆分。
DDD 和微服务是天生一对
- DDD 的子域可以很好的和微服务架构中的服务进行匹配。
- 而微服务架构中的自治化团队负责开发的概念，也跟 DDD 中每个领域模型都有一个独立团队负责开发的概念吻合。
- 子域为消除上帝类和优化服务拆分提供了好办法。
服务拆分的原则指导
在应用微服务架构时，可以采用面向对象设计中的一些原则。
单一职责原则：在面向对象中，指的是所定义的类应该只有一个职责（如果承载了多个职责，那么这个类会非常不稳定，任意一个职责变更都会引起类的修改）。在微服务架构中，设计小的、内聚的、仅仅含有单一职责的服务，这会缩小服务的大小并提升它的稳定性。
闭包原则：在面向对象中，如果两个类之间是耦合的，那么就应该把它们放在同一个包内（如果对包做出修改，那么需要调整的类都应该在这个包内）。闭包原则极大的改善了应用程序的可维护性。在微服务架构中，把根据同样原因进行变化的服务放在一个组件内，这样可以控制服务的数量。
定义服务API
定义服务 API 首先将系统操作分配给服务。某些系统操作可以由单个服务处理，但是还有很多系统操作跨越多个服务，所以接下来需要确定为了完成系统操作所需要的服务之间的协作。