[翻译]微服务设计模式 - 3. 按业务功能拆分模式

原文地址：https://microservices.io/patterns/decomposition/decompose-by-business-capability.html

背景介绍

假设你在开发一个大型复杂的微服务架构的应用，微服务架构的目标是将程序设计成一组松耦合的微服务应用，经过持续交付与部署，加速软件开发。

微服务架构经过两种方式实现这一点：

1. 简化测试，而且保证组件可以独立部署。
2. 小型的（6-10我的）且自治的团队互相协做完成软件开发，每一个小团队负责一个或多个微服务。

可是要想享受这些好处，必须将服务拆分好。微服务要足够的小，以便由一个小团队开发，而且这样更加易于测试。面向对象设计(OOD)的一个重要的指导原则就是单一职责原则(SRP)。SRP 将类的职责定义为更改这个类的缘由，并规定一个类应该只有一个更改的缘由。能够将 SRP 应用于服务设计，来设计更加内聚的服务并实现一小部分强相关的功能。

拆分微服务，还须要以一种让大多数新的和须要更改的需求只影响单个服务的方式进行拆分。这是由于影响多个服务的更改须要跨多个团队的协调，这会减缓开发速度。OOD 的另外一个有用的原则是共同封闭原则(CCP)，它指出，因为一样的缘由而改变的类应该在同一个包中。这样，当需求发生变化时，只须要修改少许的代码，理想状况下只有一个包须要改变。这种想法在设计服务时也是有指导意义的，它将有助于确保每一个更改只影响一个服务。

问题

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

考虑因素

• 总体架构须要是稳定的
• 微服务必须是内聚的，即每一个微服务应该实现一小部分强相关的功能
• 微服务设计须要按照共同封闭原则，会一块儿更改的内容，须要打包成为一个微服务，以确保每次变化只会影响一个微服务。
• 微服务必须是松散耦合的。每一个服务都是封装其实现的API，能够在不影响客户端的状况下更改实现。
• 微服务须要是可测试的
• 每一个微服务能够由一个小团队开发
• 每一个拥有一个或多个微服务的团队必须是自主的。团队必须可以独立开发和部署他们的服务，减小与其余团队的协做成本。

解决方案

定义与业务功能相对应的服务。业务功能是业务体系结构建模中的一个概念，通常是指一个为创造价值而作的事情。业务功能一般是做用于业务对象，例如：

• 订单管理负责执行订单相关操做
• 用户管理负责针对用户的操做

举例

一个线上商店一般包括下面的业务功能：

• 产品目录管理
• 库存管理
• 订单管理
• 交付管理
• …

设计对应于这些功能的微服务：

好处

这种模式有如下好处：

• 稳定的体系结构，由于业务功能的划分是相对稳定的。按照业务功能拆分微服务模块也会是稳定的，不会发生一会增长一个微服务，一会去掉一个微服务。
• 开发团队是跨功能的、自主的，而且是围绕着交付业务价值而不是技术特性而组织起来的。
• 微服务具备内聚性和松散耦合性。

问题

主要问题就是如何设计业务功能？须要理解业务才能设计好业务功能。通常业务功能是按照分析公司的目的、结构、业务流程和专业领域来设计的。经过迭代流程不断改变与扩展业务功能边界。通常能够从以下方面来开始设计业务功能：

• 公司组织结构：公司组织设计就是按照业务功能进行设计的，组织内部的不一样组可能对应于不一样的业务功能组。
• 高层次领域模型：通常业务功能会被设计成针对于某些领域对象的一些操做或者服务。

相关模式

可选择替代的另外一种设计模式是按子域拆分模式