如何进行微服务拆分

设计一个微服务架构的三步式流程：

业务能力是指一些能够为公司（或组织）产生价值的商业活动。

组织的业务能力通常是指这个组织的业务是做什么，他们通常是稳定的。与之相反，组织采用何种方式来实现它的业务能力，是随着时间不断变化的。

一个组织有哪些业务能力，是通过对组织的目标，结构和商业流程的分析得来的。

一旦确定了业务能力，就可以为每个能力或相关能力组定义服务。

围绕能力组织服务的一个关键好处是，因为它们是稳定的，所以最终的架构也将相对稳定。架构的各个组件可能会随着业务的具体实现方式的变化而发展，但架构能保持不变。

领域驱动为每一个子域定义单独的领域模型。子域是领域的一部分，领域是DDD中用来描述应用程序问题域的一个术语。识别子域跟识别业务能力一样，分析业务并识别业务的不同专业领域，分析产生的子域定义结果也会跟业务能力非常接近。

DDD把领域模型的边界称为限界上下文。限界上下文包括实现这个代码的集合。当使用微服务架构时，每一个限界上下文对应一个或一组服务。换一种说法，我们可以通过DDD的方式定义子域，并把子域对应为每一个服务，这样就完成了微服务架构的设计工作。

单一职责原则（Single Responsibility Principle，SRP）
- 改变一个类应该只有一个理由
- 设计小的，内聚的，仅仅含有单一职责的服务。这会缩小服务的大小并提升它的稳定性。
闭包原则（Common Closure Principle，CCP）
- 在包中包含的所有类应该是对同类的变化的一个集合，也就是说，如果对包做出修改，需要调整的类应该都在这个包之内。
- 把根据同样原因进行变化的服务放在一个组件内。这样做可以控制服务的数量，当需求发送变化时，变更和部署也更加容易。
- 理想情况下，一个变更只会影像一个团队和一个服务。CCP是解决分布式单体这种可怕的反模式的法宝。