​技术正在改变各行各业的发展，Gartner 的主要战略技术趋势一直是行业的技术风向标之一。近 3 年，Gartner 在主要的战略技术趋势中都提到组装式技术，2021 年首次提出组装式企业，2022 年提出可组装式应用，2023 年在 2 项主要战略技术趋势中都提到通过组装式技术来构建。

可组装式能力被频繁作为技术方向，主要是因为可组装式能力可以让企业更容易适应类似新冠疫情的变化冲击，帮助企业面向新的业务价值点、通过组装工具去把控飞速变化的风险。可组装式能力将为企业增加极大的竞争力和灵活性：

• 门槛更低：搭积木方式组装应用，降低门槛，使业务可以参与进来；

• 产品更敏捷：产品从单一解决方案转变为预先预组装的业务功能集，可更敏捷响应外部变化；

• 交付更敏捷：采用组装式方法交付新特性比竞争对手快 80%；

• 决策更敏捷：具备可组装式能力，能够在决策时做出更快的更改和响应。

那到底什么是可组装能力？如何具备才能具备可组装能力？可组装是否就是模块化、微服务？可组装架构是否就是微服务架构？

01 什么是可组装能力

可组装的几个概念定义

为了搞清楚什么是可组装能力，我们需要明确什么是可组装单元、可组装式应用和可组装式开发等概念。

概念 1：可组装单元

Gartner 把可组装的单元叫 PBC（Packaged business capabilities），翻译为中文叫做打包好的业务能力，后续我们都简称 PBC。我们摘取了 Gartner 官网的英文定义：

Packaged business capabilities(PBCs) are software components that represent a well-defined business capability ,functionally recongnziable as such by a business user.Techically,a PBC is bounded collection of a data schema and a set of services,APIs and event channels .The well-implemented PBCs are functionally complete to ensure autonomy(no critical external dependencies,no need for diret external access  its data).PBCs are meant to be used as building blocks for application product suites and custom-assembled application experiences.

从定义看，PBC 是定义良好的业务功能，可以被用户识别的软件组件；是软件组件，不是序列化的程序包，这块有区别于微服务。

从技术上讲，PBC 是有边界的集合，组成元素包含内部数据、元数据、服务、API 和事件通道。PBC 在功能上是完整的，以确保自治(没有关键的外部依赖，不需要直接访问其他组件的数据)。

概念 2：可组装式应用

结合 PBC 定义，可组装式应用就是由一系列封装好的 PBC 按业务组合。

概念 3：可组装式开发

可组装式开发就像搭积木一样把一系列 PBC 按业务组合，并开发业务场景的界面，当需求变化或流程变化时，可以通过新增、拆分、替换等方式重新组合 PBC 即可。

概念 4：可组装式架构

可组装式架构是基于 PBC 为基础，用户可以按需组合多个 PBC 加上项目化需求构建业务应用。业务封装遵从 PBC 标准。

微服务架构的主要特征为充分解耦，提供服务注册、服务发现、服务安全、熔断降级等管理，提供监控、升级、灰度等治理。可组装式架构是一种新思维，是微服务架构的进一步演进，变革了应用交付模式，采用组装式交付，通过自助方式选择 PBC 并进行组装。

组装能力评估模型

可组装能力概念清晰后，我们看下如何评估组装式能力。Gartner 给出可组装能力评估模型。评估模型从模块化、自治、可发现、可编排四个核心维度来度量企业的技术和业务抽象能力。

• 模块化：模块化是基础，也就是封装组成整个系统的每个 PBC 都必须是具有独立而完整业务逻辑的单元。信息隐藏、分离关注点、封装等是划分良好模块的方法。

• 自治：PBC 要关注边界，可以有自己的存储、数据等，不能直接去查另外一个 PBC 的数据。

• 可发现：可发现包含两个方面，一是 PBC 组件开发出来后，可以业务用户快速找到，文档足够清晰和完整，能让业务用准确评估适用性；二是指动态注册和发现，通过动态注册和发现组件来完成业务流程的动态编排和扩展。

• 可编排：基础的可编排需要支持业界通用协议，不限于特定的编程语言。PBC 组件提供者要尽可能让自己的组件可编排，比如定义好清晰的接口、做好幂等控制、支持标准协议、可扩展等方面。

02 如何具备可组装式开发能力

企业要实现可组装式的目标，需要组装平台和 PBC 一起努力达成，两者各有侧重，PBC 侧重于模块化、自治部分，组装平台侧重于可发现和可编排能力。

从可组装式开发看，需要实现组装式开发需要 PBC 和组装平台，组装平台实现 PBC 的管理、可视化组合和编排、可视化界面开发和可视化业务流程开发，PBC 是按业务场景进行封装和供给。

那我们重点看下什么是合格的 PBC，组装平台需要具备什么能力。

如何封装 PBC

基于 PBC 的定义看和组装能力评估模型，PBC 至少需要满足如下标准：

• 内部功能：包含业务模型、数据、服务；

• API：对外开放标准协议的 API；

• 消息通道：开放消息通道；

• 服务：PBC 设计层面考虑自治，考虑幂等。

除了最基础要求，封装时候还会有一些关键点需要重点关注，比如 PBC 的是否需要 UI、PBC 粒度、PBC 的可变性、PBC 的架构适配性等。

关键点 1：PBC 的 UI

针对 PBC 的 UI，我们建议是可选的。主要是考虑 UI 的变化非常频繁，布局、颜色、流程、交互方式都会频繁发生变化，PBC 不推荐包含 UI。当然，为了保证统一的 UI 风格设计，建议 PBC 组装过程通过统一的 UI 设计工具实现风格统一。

关键点 2：PBC 的粒度

PBC 封装粒度可以采用业界应用的比较多的是领域驱动方法（DDD），基于领域驱动方法，我们一般会按照实体或者聚合来划分 PBC。

关键点 3：PBC 的扩展点

PBC 是业务能力封装，要实现 PBC 的高复用，就需要考虑 PBC 适配多样化的业务场景。PBC 的设计层面可以采用共性和变化分离办法，即采用目前流行的基于业务身份的扩展点架构，分离的变化采用扩展点方式实现，不同的业务身份实现不同扩展点来支持变化的实现。

关键点 4：PBC 的架构适配性

为了考虑 PBC 复用到不同业务场景，不同业务场景可能有不同数据库、中间件等诉求。PBC 在架构层面可以比较容易实现不同数据库、中间件的迁移，最好是可以适配多种数据库、多种中间件。

基于以上关键点分析，PBC 的封装我们可以采用如下模型来表示：

PBC 的内部能力

• 基础信息：PBC 版本信息等；

• 元数据：资源定义、配置定义、流程数据、服务数据、领域模型设计等；

• 文档：提供功能介绍、使用场景、操作手册、安全检测问题、测试报告等；

• 数据：业务数据等。

PBC 的集成能力

• 外部资源依赖：外部 API 接口、消息、数据源等依赖；

• API 接口：对外提供的 API 列表，能自动发现并注册到 API 集成平台；

• 消息：对外提供消息接口；

• 数据交换：对外提供的文件数据交换等；

• 扩展点：PBC 封装时候开放的扩展点列表。

PBC 的架构适配性

• 架构适配提供的多数据库、多中间件的可选配置。

PBC 的用户界面

• 可选，页面名、URI 清单，用于 PBC 的试用和微服务页面装配。

组装式开发平台

有了合格的 PBC，那组装平台需要管理 PBC，并对 PBC 组装、编排，并按业务场景进行界面的开发，基于这些，我们认为组装平台至少需要具备如下能力：

• PBC 管理：提供 PBC 的标准和规范、上下架管理、订阅管理等全生命周期管理；

• PBC 组装和编排：提供可视化的 PBC 的组装和编排；这块就需要服务集成、数据集成、服务编排、流程编排，并需要提供 PBC 的界面开发。

  
  

组装式开发平台主要包含组装工厂、资产市场、连接与集成。

• 资产市场：统一定义资产标准和规范，提供资产目录、资产管理能力，资产上下架和使用流程流程化；资产种类包括应用模板、PBC、基础组件、页面区块、页面模板、函数等；

• 组装工厂：提供可视化工具，实现 PBC 的行组装和编排，并通过可视化设计器进行场景界面开发；

• 连接与集成：提供服务集成、数据集成、消息集成和生态集成能力，提供 PBC 的集成管理，提供应用、PBC 跟企业内外系统的集成。

当然，企业要具备组装式能力，除了组装平台和组件生态外，还需要在团队和协作模式上做一定调整。需要建立融合的团队，让业务人员和技术人员融合一起，通过快速组装方式实现业务响应和快速创新。

最后插一句，浩鲸科技灵犀平台是一个组装式开发平台，提供了 PBC 全生命周期管理、资产市场、可视化的组装工具，可以把一系列 PBC 按业务组装成不同业务应用。

​