翻译： microservices.io/patterns/cn…
上下文
你正在开发一个大型、复杂的应用程序，并希望在这个程序中使用微服务架构。微服务架构通过一组松耦合服务构建应用程序。微服务架构的目标是通过实现持续交付/部署来加快软件的开发。
- 简化测试并允许组件能够独立部署。
- 将工程组织结构化为一组小型（6-10个成员）的自治团队，每个团队负责一个或多个服务。
这些好处并非自动被保证的，相反，他们可以通过精心的把应用程序拆分为一堆相应的服务来实现。
一个服务必须足够小，小到能够被小型团队开发并且易于测试。一来自于面向对象设计（OOD)个有用的指导原则是单一职责原则（SRP。单一职责原则定义了个一个类因为某种原因需要改变，而且只能因为某种原因而改变的职责。从这种角度来看，将SRP应用到下列实践中是有意义的：
- 单个服务的设计
- 设计多个内聚的，由一系列强相关的功能的服务
还可以通过某种方式分解应用程序，以便大多数新的和更改的需求仅影响单个服务。这是因为影响多个服务的变更需要多个团队之间的协调，而这减慢了开发速度。 OOD的另一个有用原则是通用闭包原则（CCP），该原则规定，出于相同原因而更改的类应位于同一包中。 例如，两个类可能实现了同一业务规则的不同方面。 这么做的目的是当该业务规则更改时，开发人员只需要更改少量（理想情况下仅更改一个）程序包中的代码。 在设计服务时，这种思路很有意义，因为它将有助于确保每次更改仅影响一项服务。
问题
怎么把一个应用程序分解为一系列的服务？
需求
- 架构必须稳定
- 服务必须是内聚的。一个服务必须实现一小块强相关的功能。
- 服务们必须遵循通用闭包原则（出于相同原因而更改的类必须被打包在一起）以确保每个更改只影响到一个服务
- 服务必须是松耦合的（每个服务通过API封装其实现—）。服务实现的修改不应该影响到用户。
- 服务必须是可测试的。
- 每个服务必须足够小，小到可以被"两个披萨” 团队开发，例如，6-10人的团队
- 每个负责一个或者多个服务的团队必须是自治的。一个团队必须能够开发和部署他们的服务，而这只需要很少的跟其他团队的合作。
解决方案
通过定义业务能力相关的一系列服务。
相关的模式
- 根据领域的子域拆分是一个替代模式
