模式：按业务能力分解

http://microservices.io/patterns/decomposition/decompose-by-business-capability.html

上下文

您正在开发一个庞大而复杂的应用程序，并希望使用微服务架构。微服务架构将应用程序构造为一组松散耦合的服务。微服务架构的目标是通过实现持续的交付/部署来加速软件开发。

微服务架构有两种方式：

1.简化测试并使组件能够独立部署

2.将工程组织结构化为小型（6-10名成员）的团队，自主团队，每个团队负责一个或多个服务

这些好处不能自动保证。相反，它们只能通过将应用程序细致的功能分解成服务来实现。

服务必须足够小，由小团队开发，并且易于测试。面向对象设计（OOD）中一条有用指导是单一责任原则（SRP）。SRP定义了一个类的责任（responsibility）作为可变的理由，并声明一个类只应该有一个理由来改变。将SRP应用于服务设计以及设计高内聚的服务、并实现一个小的强相关的功能集是有意义的。

应用程序以某种方式进行分解，以便大多数新的和变更的需求仅影响单个服务。因为影响多个服务的变化需要跨多个团队进行协调，这会减慢开发速度。来自OOD的另一个有用的原则是通用关闭原则（CCP），其中指出，由于相同原因而改变的类应该在同一个包中。也许，例如，两个类实现相同业务规则的不同方面。目标是当业务规则改变时，开发人员只需要更改一小部分代码（理想情况下只需一个）。在设计服务时，这种思维是有意义的，因为它将有助于确保每个更改只会影响一项服务。

问题

如何将应用程序分解为服务？

目标

• 架构必须稳定
• 服务必须高内聚。一个服务应该实现一个小的强相关功能的集合。
• 服务必须符合通用关闭原则 - 一起变化的事项应该打包在一起，以确保每个更改仅影响一个服务
• 服务必须松散耦合 - 每个服务作为封装其实现的API。可以在不影响客户端的情况下更改实现
• 服务应该是可测试的
• 每个服务都足够小，由“两个比萨”团队开发，即一个6-10人的团队
• 拥有一个或多个服务的每个团队必须是自主的。一个团队必须能够通过与其他团队的最小协作来开发和部署他们的服务。

方案

定义与业务能力相对应的服务。业务能力是业务架构建模的一个概念。这是企业为了产生价值而做的事情。业务能力通常对应于业务对象，例如。

订单管理负责订单

客户管理负责客户

业务能力通常被组织成一个多层次的结构。例如，一个企业应用程序可能具有顶级类别如产品/服务开发、产品/服务交付，需求生成等。

示例

网上商店的业务功能包括：

产品目录管理
库存管理
订单管理
交货管理
...

相应的微服务架构将具有与这些能力中的每一个对应的服务。

结果上下文

这种模式具有以下好处：

•稳定的架构，因为业务能力相对稳定

•开发团队是跨职能，自主的、围绕提供业务价值而不是技术特性进行组织的

•服务高内聚和松散耦合

问题

有以下问题需要解决：

•如何识别业务能力？识别业务能力以及服务需要了解业务。通过分析组织的目的，结构，业务流程和专业领域来确定组织的业务能力。边界上下文最好使用迭代过程来识别。识别业务能力的良好起点是：

组织结构 - 组织内的不同组织可能对应于业务能力或业务能力组。

高级域模型 - 业务能力通常对应于域对象

相关模型

• 按子域分解是另一个可选模型