背景
你正在开发一个大型，复杂的应用程序，并且使用微服务架构。微服务架构将应用程序组织为松散耦合的一组服务。微服务架构的目标是通过启用持续交付/部署提高开发速度。
image
微服务架构通过以下两种方式做到这点：
- 简单化测试，并且允许组件独立部署
- 将工程师组织为小的（6 - 10个成员），自动化的团队，每个团队负责一个或多个服务
这些优点不是自动保证的。相反，他们只有小心的将应用功能拆分成服务才能达到。
一个服务必须足够小，以给小型团队开发和容易测试。一个从面向对象设计（OOD）而来的有用的指导，是单一职责原理（SRP）。SRP将类的职责定义为变化的原因，同时指出一个类有且只有一个原因发生改变。将SRP应用到服务设计，同时将服务设计为实现了一组强关联的功能的结合，是非常有意义的。
应用通常采用一种方式拆分，这样多数新需求，和需求变更，近影响单一服务。这是由于影响多个服务的变更，需要跨多个部门协调，这会减缓开发速度。另外一个从OOD由来的有用的原理，是共同闭合原理（CCP），它指出相同原因发生改变的类应该在同一个包。例如，两个类可能实现了相同业务规则的不同方面。最终目标是，当业务规则改变了开发人员，仅需要改动（理想情况下一个）包里很少的代码。设计服务时，这样的思考很有意义，它将帮助确保变更仅影响一个服务。
困难
如何拆分应用程序到服务？
限制
- 架构必须稳定
- 服务必须有凝聚力。一个服务应当实现一小组强关联的功能。
- 服务必须符合共同闭合原理 - 一起变更的事物应该打包在一起 - 确保变更仅影响一个服务
- 服务必须松散耦合 - 每个服务作为API封装了它的实现。这些实现在不影响客户端的情况下发生更改。
- 服务需要可测试
- 每个服务需要小到足够“2个披萨”团队开发，例如：6-10人的团队
- 每个拥有一个或多个服务的团队必须是自治的。团队应该在最小程度与其他团队合作的情况下，开发和部署他们的服务。
解决方案
定义服务与业务能力对应。业务能力是业务架构建模的概念。这是业务为了产生价值所做的事情。业务能力通常对应为业务模型，例如：
- Order Management为订单负责
- Customer Management为客户负责
业务能力通常组织为多层结构。例如，一个企业应用可能有顶级的分类，比如Prudoct/Service development，Product/Service delivery，Demand generation等等
例子
在线商店的业务能力包括：
- 产品分类管理
- 库存管理
- 订单管理
- 物流管理
- 。。。
相应的微服务架构，需要拥有对应每个业务能力的服务。
image
结果
这个模式有以下优势：
- 由于业务能力相对稳定，这个架构也很稳定
- 开发团队是跨功能的，自治的，按产生业务价值组织而不是技术特点组织
- 服务是凝聚的，且松散耦合
问题
有以下问题需要解决：
-
如何标识业务能力？标识业务能力和服务需要对业务的理解。标识一个公司的业务能力，可以分析公司的目标，组织结构，业务行为，专业领域。在迭代中最好标识出一个有界上下文。标识业务能力的起点最好是：
- 组织架构 - 公司里的不同小组业务对业务能力或者业务能力小组负责
- 高层次领域模型 - 业务能力通常对领域模型负责
关联的模式
- 按子域拆分 是另外一种替代模式
