可复用架构是进行架构设计非常重要的思维之一，是面向对象架构设计的核心思想。复用可以让我们站在巨人的肩膀上，基于已有的成果，快速构建一个新系统。我们可以通过中台和DDD（领域驱动设计）等方法构建企业级和业务领域的服务，虽然能很好地划分了中台和面向业务领域的服务，但是在一些业务流程比较复杂的业务，我们还是要花费大量的成本去组合和编排不同项目的业务流程来实现最终的业务价值。那么有没有很好的方法来快速构建业务流程并实现业务价值呢？

答案是有的。本文会从软件架构的复用层次、业务流程复用、业务流程建模和实现来揭晓答案。

一、可复用的软件架构的层次

我们常说代码复用，组件复用，领域模型复用等，那么可复用的软件架构有哪些复用层次呢？

1.1 技术复用

首先是代码级复用，其中包括自己或他人的类库，三方的 SDK，其他算法封装等。我们的代码可以直接调用它们，也和我们的应用打包在一起，运行在同一个进程里。代码级复用是最低层次的复用，我们可以把它当作你自己源代码的一部分。

往上就是技术组件复用。这些组件我们自己可以封装的，更多的是大量开源的中间件，比如 Redis、Rocket MQ、Dubbo 等；组件也包括各种开发框架如 Spring boot。这些基础组件技术复杂度很高，它们的存在，极大地简化了我们的开发工作。

代码级复用和技术组件复用都属于工具层面，在不同的业务下都可以用，但和业务场景隔得有点远，不直接对应业务功能，复用度较高。

1.2 业务复用

软件最终是为业务而服务的，如果能够直接实现的业务复用，那项目实施的效率就越高。在一家企业有不同业务能力的复用，比如微服务强调单个业务实体的封装和复用，而中台进一步实现了企业级业务能力的复用。

所以接下来，我们就从比较简单的业务实体复用开始说起。业务实体在DDD中叫做领域模型，它的复用针对细分的业务领域，比如订单、商品、用户等领域。它对各个业务领域的数据和业务规则进行封装，将它变成上层应用系统可以直接使用的业务组件。

业务流程的复用针对的是业务场景，它可以把多个业务实体和不同业务领域服务、中台和基础平台等系统组合和编排起来，完成一个端到端的业务流程。比如说，下单流程需要访问会员、商品、订单、库存等多个业务，如果我们把这些调用逻辑封装为一个下单流程服务，那下单页面就可以调用这个流程服务来完成下单，而不需要去深入了解下单的具体过程。相比单个的业务实体复用，业务流程的复用程度更高，业务价值也更大。

最高层次的复用是对整个系统的复用，比如说一个 SaaS 系统（Software-as-a-Service），它在内部做了各种通用化设计，允许我们通过各种参数配置，得到我们想要的功能；或者说一个 PaaS（Platform-as-a-Service）平台，它会提供可编程的插件化支持，允许我们“嵌入”外部代码，实现想要的功能。这种产品级的复用，它的复用程度无疑是最高的。在项目落地的时候，它无需核心的开发团队进行开发，只由外围的实施团队负责就可以了，这样，一个项目的上线就能简化为一次快速的实施，不但上线周期短，系统也更稳定。当然，实现这样的复用，难度也是很大的，你既要对所在行业的业务有很全面的理解，又要有很强的抽象设计能力。这类系统中，比较典型的有 Salesforce 的 CRM 系统和 SAP 的 ERP 系统。

综上所述，从技术复用到业务复用，越往上，由于业务多变性，复用度越低，但复用产生的价值也越大，但实现起来也越复杂，它能复用的场景就越有限。在实际工作中，技术层面上的复用相对比较简单，我们对这部分的认知也最多，有丰富的中间件可供我们选择，我们可以逐步构建适合自己的技术体系。

业务上的复用比纯粹的技术复用有更高的价值，我们需要往这个方向上努力。如果我们能进一步打造产品级和业务流程中间件，并在这个基础上，形成业务平台，这样，我们就能实现更高的业务级复用，可以更高效地支持系统的快速落地。

二、微服务或中台边界划分

我们通常采用 DDD 的方法来找到对应的领域模型（业务实体），通过限界上下文指导微服务和中台的划分，在这里我们就不在赘述了。

上图是我们常见的进程间架构，业务实体（领域模型）主要是在中台或者领域服务层。我们构建产品级或者业务流程级别往往在前端和BFF或前台来进行。由于前端的相关展示等数据通常来自前台或BFF，此处我们就讨论在前台或BFF进行产品业务流程的设计。

三、构建价值交付的高速路

此维度主要对企业的产品业务流程进行分层建模，分析企业如何通过一系列业务活动，按照相关的业务规则将输入转换成为有业务价值的输出，从而实现用户价值。

在我们很多软件开发项目中，中台和微服务划分并建设后，往往中台相对稳定，但是前端和前台或BFF的业务变化频率要高于中台，所以我们需要大量的成本进行产品业务流程的设计和实现。此处我们以电商场景为例，来看看如何做好产品流程复用并构建价值交付的高速路。

在电商场景中，购买不同品类的商品，业务流程也会有非常大的差异。例如：买卖实物商品的流程一般是：买家付款、卖家发货、买家确认收货；买卖酒店房间的流程一般是：买家付款、卖家预留客房、买家入驻、买家退房结单；买卖旅游线路的流程一般是：买家付款、卖家确认、服务履约。

这些业务场景、交易流程虽然有较大的的差异，但是他们可以共同复用核心的交易流程。我们可以采用 DDD 中的共享内核的模式进行流程建模，如下图活动中的主干交易所示。

3.1 如何进行流程建模

流程建模是负责识别共性业务，并抽取通用流程，设计可变点，作为可复用性分析的基础。为了提取可复用的能力，首先需要识别共性业务，然后将同一类共性的业务抽象提炼出通用流程，并基于通用流程进行可变性分析。

我们可以按业务架构中流程部分的元模型(阶段、活动、任务、步骤、业务规则)，结合自上而下以及自下而上的方式逐层提炼收敛通用模型和可变点。

阶段：即业务流程阶段，包含一组用户的及与用户交互的业务活动，用以实现阶段性价值交付的目的。比如：售前、售中和售后等。

活动：即业务活动，是某个业务角色办理的业务事项，包含一个或一组任务，有明确的业务成果和业务输出。比如：商品发布、活动发布等。

任务：是完成活动的工作程序，是流程的基本组成单元。比如：查询商品详情、更新商品库存、创建订单等。

步骤：是完成任务的具体步骤，是流程的最原子操作。比如：校验用户状态、校验商户状态、订单总价试算等。

业务规则：是定义或约束业务某些方面的陈述，旨在维护业务结构或控制或影响业务行为，它描述业务过程与决策过程。比如：if 订单. 提货方式=“邮寄” 且订单 . 支付状态 =“已支付”then“创建物流单”。

如下是这个几个流程建元模型的概念关系图。

根据上面所述的方法，我们对本节开始的电商场景的例子进行了建模，结果如下，仅供参考。

3.3 价值交付的高速路

上面的建模结果没有把业务规则详细地体现出来，但通过上面的阶段、活动、任务和步骤的建模，我们就能很快地发现电商业务流程的高速路（主干交易+扩展点）。在这个场景中，主干交易是图中蓝色底色标志的活动；有两个可扩展点，一个是卖家确认和买家确认。针对于每一个活动，我们可以拆分多个任务，其中任务可以跨越不同活动，如库存校验就在添加购物车和买家创建订单的两个活动中；每一个任务可以拆分成多个步骤，其中步骤可以跨越不同任务，如订单状态更新等。

3.3 高速路的实现

上面我们已经构建出了价值交付的高速路，现在有一些开源框架可以帮助我们构建业务流程，但是往往没有显式化地构建出活动、任务和步骤。此时就需要我们自己可以构建出活动、任务和步骤等业务组件来进行架构设计，此时我们看一下在进程内的架构和我们这些流程元模型的对应关系。通过业务概念显式化，我们就能使得我们的代码实现与流程模型保持一致，流程模型与产品业务流程保持一致了。当然由于涉及到业务流程，团队可以根据自己的情况构建出流程引擎来满足流程调度和状态跟踪等，此处不做详细描述了。

四、总结

本文主考虑到了很多团队面临的实际情况，在中台或领域服务已经确定的时候，如何能通过产品业务流程复用来快速进行价值交付的高速路。当然在从0到1构建的过程中，我们要先考虑业务流程的复用，可以先进行流程建模，清晰可复用的产品业务流程，然后再进行领域建模，划分出合理的领域服务或者中台。在合理的边界划分和可复用产品业务流程，我们就能够快速地通过业务流程构建的高速路迅速实现业务价值。

ITPub博客

可复用软件架构：通过产品业务流程复用构建价值交付的高速路