​一、引言

组装式应用程序是Gartner在《2022年重要战略技术趋势》中提出的十二项技术之一，主要是通过引入模块化的PBC使技术和业务团队可以更敏捷、更有效地重用代码。那么PBC是什么？

业务能力包(PBC)是一种软件定义的最小化的业务功能，专注于解决特定的业务问题。业务用户在功能上可识别这些功能，旨在用于应用程序产品套件和自定义组装应用程序体验的构建基块。PBC是数据架构和一组服务、API和事件通道的有界集合，可以被视为微服务的聚合,在功能上是完整、自治的体系，具有四大特性。

• 模块化：分成一组有凝聚力的组件。
• 自主性：自给自足，并具有最小的依赖性，以确保组成的灵活性。
• 编排式：通过 API、事件接口或其他技术手段，打包组合到流程流程或复杂事务中。
• 可发现：语义清晰和经济的设计，使业务和技术设计者、开发者和活跃的应用程序都能访问。

其中在编排式上，围绕PBC和它的编排能力，带来的问题就是我们本次特别引出的组装式。从图中可以看出原来有三个不同颜色的PBC，我们通过一定的方式对这三个PBC进行组装从而形成一个新的应用，从而对外提供能力。

Gartner表示：“在动荡的时代，可组合的业务原则帮助企业机构驾驭对业务韧性和增长至关重要的加速变化。可组合的应用架构增强了业务适应性，而采用可组合方法的企业机构在新功能的实现速度上将比竞争对手快80%。”

在这个组装过程中，必然有很多问题需要我们去探索和实践：

• 如何组装？
• 组装的标准是什么？
• 组装时是否会存在一些安全风险？
• ……

那么我行当时在建设的时候，为什么会对标组装式应用程序，是如何引进这个概念并且落地实施的？围绕这个问题，首先介绍我行当时在建设时面临的问题。

我行近几年在大力建设金融生态场景，对外提供了很多SaaS应用，这一部分除了我行自建之外，我们也会与一些合作方进行合作。随着无界融合、优势互补、开放共赢的金融生态圈的不断发展，我行在面对客户快速推出生态产品、提供一站式解决方案方面存在一定不足，以支撑应用组装式开发方面有待提升，总结起来主要有以下四个方面的能力欠缺，分为技术和管理两个部分：

技术上：

1）生态融合

缺乏统一的产品目录和产品能力，没有形成市场化的建设；

生态缺乏通用的基础服务，如用户、权限、流程、数据访问能力和用户交互界面。

2）场景复用

非金融功能重复建设，独立研发，缺乏场景级能力输出；

金融功能存在各场景重复封装。

管理上：

3）标准技术建设方案

生态建设统一标准有待完善，功能耦合度高，无法实现能力复用，导致重复造轮子，应用搭建效率低；

新场景建设需求日益频繁，缺乏基于既有场景快速组装能力的支撑。

4）统一管理运营

缺乏功能场景、共享服务标准、数据标准的统一管理标准；

缺乏生态场景级的可复用基础框架、构件需求管理。

当时我们面对SaaS产品的建设中主要存在刚才提到的这些问题，未来我们如果还要更快速地发展，更快速地推出产品，我们必须针对问题提出一些解决方案。因此我们围绕这些问题对标业界，发现组装式开发在技术和业务方面都有一定的优势，能够快速组装现有的业务能力，推出一个新的应用产品，最终我们选择了组装式应用程序开发落地。

二、生态连接器建设

接下来介绍我们的生态连接器建设，这是我们当时在落地的时候形成的总体架构图：

1、建设通用基础服务

我们需要做一些生态融合，解决组装的能力问题，其实就是要建设好通用的基础能力。实现通用用户、权限、角色、机构、流程管理等基础服务，提供数据共享访问，打通生态产品场景融合。

在基础能力方面，用户中心、权限管理和流程管理是比较基础的，以及用户菜单、角色、机构等，基本上我们的每个SaaS应用建设时都会涉及，包括与行外合作方提供的SaaS应用进行融合的时候，都必须包含流程管理等基础能力，这一方面是作为融合能力重点建设。

2、建设业务共享服务标准化输出能力

在融合的过程中，我们需要提炼一些共性的业务共享服务(PBC)，类似于前几年提的中台，比如资金监管、项目中心、流程中心，并且围绕这些能力支持PBC建设的配置化，比如样式的自动适配、数据标准，以及快速组装，我们也会专门制定一套数据共享的访问，从而解决各个上市产品之间数据共享，以及数据共享中存在的安全问题和标准问题，实现数据标准化转换和打通，实现产品场景的快速组装能力和标准化能力。

3、提供研发支持基础框架

在融合的基础之上，从架构的分层来看，最底下就是提供基础的技术能力支撑平台，建立产品组装平台快速构筑产品，以及一些技术标准框架，类似于我们业界熟知的Spring Boot，我们可能也会在上面做一定的封装，形成适合我们应用的框架内容。

有了这些PBC的业务能力之后，我们会面向不同生态场景，比如当前国家在推广乡村振兴，那么在这一方面我们也会推出一些对应的SaaS产品供乡村使用。

在生态场景的概念之上，我们额外提出了一个生态解决方案。从客户角度来说，比如乡村振兴的生态场景，除了管理村里的一些事务之外，可能也需要党员管理，从技术层面我们关注的是场景和应用，但对于客户而言，他关注的是功能和能力。未来我们会更进一步，面向不同的群体提供一些生态解决方案，比如智慧教育、智慧政务、新管家等。

借助于组装式应用程序开发理念，我们层层往上，通过不同的PBC形成一个新的生态场景，再通过不同的生态场景形成一个新的生态解决方案，从而打造生态场景融合能力+业务共享服务输出+技术标准能力支撑，并配套完整的生态管理体系，实现生态场景快速建设，提供端到端统一服务的目标，这是我们的生态连接器上的总体建设。

三、业务服务包(PBC)落地

从业务能力上来说，核心在于PBC的建设，所以着重再跟大家分享一下我们PBC落地的架构层面和设计层面上的规划，从外部市场也就是客户的视角梳理一些场景。

我行做得比较多的是一些金融的场景，对于我们来说，我们的概念中更多区分的也是金融和非金融，但其它一些企业在落地的时候，可能会有其它划分类型。

我行提供的金融服务是比较丰富的，代收、支付、账户管理、资金监管，都是银行传统的优势方面内容，然后我们重新整合形成共享服务包，为后面的产品快速上线提供支撑。

生态场景的不断丰富，也带来了一些新的非金融服务能力，我们将其划分为通用领域和专用领域。

通用领域即基本上每个领域都能用到的，比如流程中心、积分管理。从客户服务的角度分析，基本上都会设置积分，所以我们将积分管理设置为通用领域。

专用领域则是面向于特定的某一类场景或解决方案，将共性的内容抽取出来。

在具体实施的时候，我们也是对标组装式应用开发和PBC的概念，支持“模块化、自主性、可发现、可配置”，其实关键点在于支持数据标准转换和对外统一标准的服务输出，包括统一数据字段、统一接口标准、统一UI风格转化。

尤其是UI风格方面，我们所说的统一UI风格，指的是统一UI风格的设计理念。面向不同的客户提供的SaaS产品，客户在UI风格上可能会有不同的需求，比如党建方面则是红色的颜色会偏多一些。同一个共享服务包，需要支持面向不同的客户群体和SaaS产品能通过统一的UI风格进行适配。在最底层我们的技术细节实现的时候，也会支撑统一的数据字段、数据标准的转化。如果共享服务包在组装的时候缺少了一套统一的标准，那么组装的时候必然会存在一些问题。

我们对于PBC落地的技术要求和管理要求如下：

1、技术要求

配置能力暴露：暴露菜单、页面UI配置接口，在产品复用业务时初始化设置菜单、实现UI配置等配置功能的设置和初始化。

应用接口暴露：根据DDD思路对共享服务抽取接口，形成场景化的业务能力组合，并在组装平台进行发现。

对外输出：支持转换为开发态的业务组件，提供行外独立部署。

2、管理要求

开展牵头应用承建机制：由领域负责应用承接进行建设，按照单独建设群组方式进行共享。

场景建设：在智慧教育、乡村振兴、政务等重点战略重点突破，形成相关领域的业务能力包。

四、组装式应用开发

围绕业务服务包的建设，我们当时也对标了组装式应用开发的理念。

1、金融生态应用组装平台

我们规划建设了一个金融生态应用组装平台，平台主要分为三个部分：

首先是元数据目录，比如数据编排、数据标准和数据的动态集成，未来可能还有知识图谱等概念做一些基础的支撑；

元数据目录再上一层是应用模板，面向不同的场景，我们需要制定出不同的应用模板；

最上层是可视化建设，针对不同模板下的业务服务包(PBC)进行组装，同时也有支撑PBC建设的技术组件，通过平台自由组装。

通过这三层实现增量功能，包括增量产品、存量产品的快速生产，对于新产品可以通过组装快速生成整个应用，存量则更多考虑如何兼容和升级。

2、DDD设计思路

在实际落地开发的时候，对于PBC如何划分，内部提供了什么能力等问题，需要一套方法论支撑。业界上近几年微服务比较热门，DDD的思路也是用得比较多的，我们行内有一套业务建模的方法与DDD是相通的，通过建模梳理出了PBC的一些能力。第二步就是生成PBC，因为组装是一个积木的概念，所以需要先生成积木，再组装积木，最后生成一个完整的工程。

在业务建模方面，我们采用DDD设计思路，在架构层面引入六边形架构。因为我们在建设的时候，传统的应用会有一些分层的概念，但是代码可能会串层，发生逻辑的上移或下移，我们通过六边形架构诠释应用内部和外部差别，内外部通过适配器交互进行隔离，内部聚焦领域服务，从而实现稳态领域层和适配层解耦。

从上图可以看出，我们在原始的六边形架构上做了一些延伸，也就是6个标红的部分。我们在落地这套领域驱动设计的架构时，领域层聚焦于领域模型对象、领域服务、应用服务的设计和组合。相当于在业务建模的时候，会识别出来有哪些领域对象，围绕着这些对象会有哪些服务和应用，这是最核心的内容。

对象工厂、领域事件和仓储，我们的理解一定程度上是属于技术实现，在技术实现上，通过面向对象的设计以及设计模式的引入，在对象创建、对象交互上达到灵活解耦。

对象工厂用于创建对象；

领域事件用于对象之间的信息交互和解耦；

仓储用于数据交换，比如我们在落地时，需要引入一些存量应用，一个实体可能对应到多张表，多张表则需要做一些拆分和整合，因此在仓储上会做一些额外的工作内容。

针对这套DDD标准架构的落地，我们会有一个标准工程结构，明确工程结构设计，设计者可以和代码阅读者交流领域和架构的设计意图。围绕这套工程建设，我们也有一套配套的工具支撑，总结标准应用结构生成、依赖检查工具、标准资产组件/工具推荐等，一系列工具资产保证架构落地。

接下来我们通过一个例子介绍DDD的设计思路落地。其实DDD最核心的是一些聚合根和实体对象的抽取。我们行内有一套就是业务建模方法与DDD理论一脉相承，DDD里的事件风暴我们行内称为业务用例，就是通过一段话与业务人员讨论业务场景和业务能力。主要流程如下：

首先找一些名词，给这些名词加上属性，通过名词之间的关系形成一个实体领域模型，我们称为业务对象；

其次将实体对象进行聚合形成一个聚合根；

最后围绕这些实体模型找一些相关的动作，如支付、提交，从而形成领域服务、交易服务等能力。

以某代理保险销售应用为例：抽取保险协议的实体和值对象，做抽象类的聚合和设计。实体分为财险保单和寿险保单两大类，值对象指的是保单上的各种属性，包括产品信息、公司信息、保单期限、费率信息等。未来我们在值对象设计上可能会做一些技术手段，通过定制手段自动化地动态展示前台页面等，形成了整个聚合根和实体的值对象，从事件风暴来讲，也就是梳理出用例，再进行组装式的开发。

3、低代码能力

组装式开发离不开近几年一直在谈的低代码能力，我们也是通过低代码能力进行落地实践。

采用低代码能力，生成代码符合标准工程代码结构，应用可自定义连接不同数据实体，基于实体自动生成对应的领域服务等相关PBC积木块内容，同是针对多实体聚合可复用DDD设计的聚合根对象预先在数据库创建虚拟实体从而自动生成。自动生成有以下几点需要注意：

我们传统针对表，实体可能是get、set方法，在DDD领域里其实是贫血模型，未来我们设计一种充血模型，也就是实体还是会带一些方法，我们现在已经能够比较好地支持针对于实体的增删改查的能力，围绕实体生成对象服务。

我们在选中实体生成代码时，可以进行一定的定制，在增删改查的基础上，我们平台会更多提供扩展能力的支持，比如聚合，平台通过类似于DSL等一些脚本的能力对其进行定制，读取我们定制的一些内容，自动生成这一部分代码。

除了对象服务之外，围绕实体也可能会有一些简单的领域服务，也就是图中标的业务服务，另外，我们行内在单元测试方面也是落地比较深的，因此所有代码我们都必须有对应的单元测试覆盖。我们目前生成的单元测试符合行业要求，生成单元测试之后也是按照标准代码结构生成代码，图中示例是以某应用中产品信息实体为例。

针对实体对象生成的能力，比如增删改查，我们抽取了多个应用进行分析，以某应用为例，应用中涉及80多张表（占比30%）可以一次性通过低代码平台直接生成，加速研发效率，剩下的可能需要额外进行组装和定制再生成。

至此我们已经通过建模建出实体对象，也通过低代码方式自动生成了围绕这些实体对象的一些基础能力，这一部分能力就是我们之前提到的积木。

4、组装

有了积木块建设之后，我们接下来要进行的是积木块的组装，这一部分也是通过组装式应用开发平台完成。

1）整体设计

基于组装式应用开发平台，遵循“积木式”开发思想，按分层结构去做，通过日益丰富的技术积木块和业务积木块的灵活组装，助力应用快速搭建应用基础框架。

自动生成代码符合标准化目录指引和包命名规则，从架构设计到代码生成是标准的一一对应关系，统一项目研发，引导开发人员践行DDD模式。

根据清晰的工程目录覆盖对象设计的不同能力，形成稳态和敏态的有效区分，隔离围绕对象自身的建设和对业务场景的建设，进一步展现围绕对象开展系统建设的逻辑视图。

2）业务组件编排

整体设计完之后，通过业务组件编排进行积木组装，这一方面与低代码能力也是息息相关的。业务组件编排基于低代码能力生成的对象服务和业务服务进行自由组装，可实现对象服务组装生成新业务服务，也可支持业务服务组装生成交易服务。

上图的左侧就是我们针对业务积木的组装，业务积木块有不同的分类，比如保险、教培等，同时权限中心、流程中心、认证中心等基础能力也包含在目录里，按一级、二级不同的目录结构提供选择。我们的技术人员要组装成一个服务能力时，即可通过该平台进行一些逻辑关系的组装，比如可以在每条线上制定一些表达式条件，当某个值等于多少时则往哪个分支去做，从而通过组装重新形成新的服务，完成对整个PBC内部的一些能力建设，形成一个新的PBC对外提供能力。

在目录建设的时候，我们按照不同的PBC划分模块化，生成的服务采用模块化开发思想进行组织，不同的服务聚合于不同的物理目录下作为子工程存在，各服务子工程可独立开发。不同的人或团队能够各自管理和维护各自的PBC能力，从IT架构指导组织架构调优，进一步提升开发解耦。

3）技术组件编排

技术组件编排通过对接已有技术能力，支持基础能力以及技术组件的快速组装。行内通过共建形成了一套标准的技术组件，可以将建设好的技术组件直接引入平台，令大家自行选择需要的组件和能力，从而为整个PBC的建设包括应用建设形成组装。

5、生成应用工程

完成业务和技术的组装之后，最后一步是生成整个应用工程。

1）首先是一站式生成应用基础框架，统一一站式技术底座，大大提升应用工程搭建效率。我们引进了多套模板，如DDD、分层架构等，不断丰富应用基础框架，同时针对不同的节点梳理它们不同的能力，从而通过组装平台生成不同的节点的标准工程，如接入层节点则是路由、灰度、限流比较重要，批量的数据处理则进行文件导入导出的一些技术构件。

2）一键快速运维能力接入，解决运维能力使用的最后一公里。平台所提供10余种生产运维组件包括应用监控、自隔离、人机密码分离等基础运维能力，自动集成应用的一些能力建设，避免重复造轮子。

3）对标云原生能力，自动生成PaaS镜像模板，解决了PaaS镜像不同环境变量配置的问题，实现了PaaS镜像模板制定从数天到分钟级的跨越，大大提升上云效率。

在Gartner提出的PBC如何组装建设的基础之上，我们对于PBC内部如何聚焦、组装和建设做了更多更深层次的延伸，不只PBC间实现组装，在PBC内建设时也支持组装式开发。

五、未来展望

1、标准能力

在实现行内PBC以及未来行外合作方PBC接入后，实现PBC之间的组装需要制定一套标准的组装规范，统一组装能力，中国信通院也在今年7月份提出组装式应用开发，并组织相关企业准备制定相应规范，我行也将择机参与，以便融入行业生态，将着重从以下五方面推进：

通用能力：包括我们的通用工程、标准工程以及标准集成的一些能力，在落地时针对细分的不同类型制定不同的标准工程会更加精细化；

性能：生成的代码是否存在性能问题；

安全：代码生成是否安全；

适配：在标准工程生成时，比如Web节点上的XSS攻击，能够自动集成防XSS等的组件，进行页面适配或组装适配；

代码：代码的自研能力，以及低代码生成能力。

2、数据共享、数据标准、数据血缘

数据共享： PBC之间的一些衔接、交互；

数据标准：数据共享如何制定标准，我们是通过单独的SDK包内部做一些数据共享的标准检验、安全管控等内容；

数据血缘：未来规划要做数据血缘关系的分析，也就是将完成PBC组装的数据共享和衔接之后的最终数据做一些大数据分析，在这个基础上探索做数据血缘关系的分析，从而为后面SaaS产品的数据运营方面提供一些指导工作。

Q&A

Q1：落地组装式应用程序技术需要先落地DDD吗？

A1：从微服务角度，以及我们PBC建设的一些划分、识别来说，DDD这套方法论对于通过DDD建模建出来的一些实体的归属划分关系非常契合，因此我们认为先落地DDD再落地组装式应用程序技术会更便捷。

Q2：什么类型的企业适合落地组装式应用程序？

A2：这个问题的本质就是组装式应用程序技术的提出是为了解决什么问题。Gartner当时提出这项技术，以及我们国内一些大厂在落地这方面内容时，核心就是在业务快速发展、企业环境急剧变化的情况下，如何快速提供新能力和组装新产品。因此如果企业想要快速抢占市场，或者业务变化比较频繁，那么就适合落地组装式应用程序。

作者介绍

张建荣：大型银行 软件开发中心高级经理

资深架构师，杭州研发部领域专家，负责技术管理、架构转型等相关工作。2007年加入大型银行软件开发中心，致力于推动技术创新、效能提升，实现业务价值的高质量快速交付；先后牵头信贷、票据、养老金、智慧政法等产品线和数字生态基座（组装式应用程序Composable Applications）等多个大型系统建设；并作为技术专家，为安全生产提供技术支持。