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

背景介绍

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

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

简化测试，并且保证组件能够独立部署。
小型的（6-10个人）且自治的团队互相协作完成软件开发，每个小团队负责一个或多个微服务。

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

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

问题

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

考虑因素

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

解决方案

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

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

举例

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

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

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

好处

这种模式有以下好处：

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

问题

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

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

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

背景介绍

问题

考虑因素

解决方案

举例

好处

问题

相关模式

更多相关文章

随机推荐