架构模式: 根据业务能力拆分
上下文
您正在开发一个大型，复杂的应用程序，并希望使用微服务架构。微服务架构将应用程序构建为一组松散耦合的服务。微服务架构的目标是通过实现持续交付/部署来加速软件开发。
微服务架构以两种方式实现：
- 简化测试并使组件能够独立部署
- 将工程组织构建为小型（6-10个成员）自治团队的集合，每个团队负责一个或多个服务
这些好处不会自动得到保证。相反，它们只能通过将应用程序细致地功能分解为服务来实现。
服务必须小到足以由小团队开发并且易于测试。面向对象设计（OOD）的一个有用的指导原则是单一责任原则（SRP）。SRP将类的责任定义为改变的理由，并声明类只应有一个改变的理由。将SRP应用于服务设计以及设计具有凝聚力的服务并实现一小组强相关功能是有意义的。
应用程序也以某种方式进行分解，以便大多数新的和更改的要求仅影响单个服务。这是因为影响多个服务的更改需要跨多个团队进行协调，这会降低开发速度。OOD的另一个有用原则是Common Closure Principle（CCP），它声明由于同样的原因而改变的类应该在同一个包中。例如，也许两个类实现了同一业务规则的不同方面。目标是当业务规则改变开发人员时，只需要更改少量代码（最好只有一个）的代码。在设计服务时，这种想法很有意义，因为它有助于确保每项更改只影响一项服务。
问题
如何将应用程序分解为服务？
要点
- 架构必须稳定
- 服务必须具有凝聚力。服务应该实现一小组强相关的功能。
- 服务必须符合通用关闭原则 - 将一起更改的内容打包在一起 - 以确保每个更改仅影响一个服务
- 服务必须松散耦合 - 每个服务作为封装其实现的API。可以在不影响客户端的情况下更改实现
- 服务应该是可测试的
- 每项服务都小到足以由“两个披萨”团队开发，即一个6-10人的团队
- 拥有一项或多项服务的每个团队必须是自治的。团队必须能够与其他团队进行最少的协作来开发和部署他们的服务。
结论
定义与业务功能相对应的服务。业务功能是业务架构建模的概念。这是企业为了创造价值所做的事情。业务能力通常对应于业务对象，例如业务对象。
- 订单管理负责订单
- 客户管理负责客户
业务功能通常组织为多级层次结构。例如，企业应用程序可能具有顶级类别，例如产品/服务开发，产品/服务交付，需求生成等。
例子
在线商店的业务能力包括：
- 产品目录管理
- 库存管理
- 订单管理
- 交货管理
- …
相应的微服务架构将具有与这些能力中的每一个相对应的服务。
结果上线文
这种模式具有以下好处：
- 稳定的架构，因为业务能力相对稳定
- 开发团队跨职能，自主，有组织地提供业务价值而非技术特征
- 服务具有凝聚力和松散耦合
问题
有以下问题需要解决：
-
如何识别业务能力？识别业务能力和服务需要了解业务。通过分析组织的目的，结构，业务流程和专业领域来识别组织的业务能力。使用迭代过程可以最好地识别有界上下文。识别业务能力的良好起点是：
- 组织结构 - 组织内的不同组可能对应于业务功能或业务功能组。
- 高级域模型 - 业务功能通常对应于域对象