2021年，Gartner给出2022年Top Strategic Technology Trends，列出的12项前沿技术中，包括了组合式应用（Composable Applications）。同时，Gartner预测，到2024年, 新的SaaS应用和自定义应用都将是“composable API-first or API-only”。这种可组装API优先或API唯一的方式，甚至可以认为是现代应用的一种特征，可以概况为开放和组合。
组合式应用由PBCs（packaged-business capabilities）构成，也可以将PBC称之为软件定义业务对象（software-defined business object）。这就是PBC概念的由来。
PBC的定义
Packaged business capabilities (PBCs) are software components representing a well-defined business capability, functionally recognizable as such by a business user. Technically, a PBC is a 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 direct external access to its data). PBCs are meant to be used as building blocks for application product suites and custom-assembled application experiences.
以上为Gatner对PBC的定义。从这一详细定义可以明确PBC面向业务用户，为其提供相对独立的业务能力。
技术上，PBC的外部公开为APIs与Event Channel，内部则由服务（可以是微服务，也可以是迷你服务或宏服务）、内部数据与元数据构成，同时，还包含可选的用户界面。整个PBC的结构如下图所示：
这一特征也吻合我在应用现代化白皮书中对开放能力的定义，即“开放为用，内聚为体”：
PBC的开放就是API与事件通道，PBC的内聚则体现为它所拥有的数据和元数据，而业务代码则定义为各个独立的服务。
PBC的特征
Gatner定义的PBC具有以下的核心特征：
- 模块化
- 可发现
- 自治
- 可编排
我认为可以从业务维度与技术维度分别定义PBC的特征：
- 业务维度：代表一种完善的业务能力，可被业务用户理解
o业务导向o灵活组合o独立售卖
- 技术维度：封装完好的软件组件，并以开放的API向外公开
o设计要素：§发现§开放§扩展§自治o质量属性§可移植性§互操作性§弹性伸缩§韧性可靠
PBC的分类
根据PBC的业务特征，以及它对外提供的能力，可以分为以下五类：
- 业务PBC：提供相对完整的业务功能，如订单管理、合同管理等
- 流程PBC：封装了业务流程的完整业务能力，如工单审批流程、贷款申请流程等
- 数字孪生PBC：物理世界中人（People）、位置（Place）和物（Thing），即所谓的PPT对象到数字世界的映射，如工厂产线、零售网点等
- 数据PBC：提供数据信息，并形成信息汇总和画像能力，如员工画像、规则库、凭证等
- 分析PBC：对数据进行洞察和预测等分析能力，如动态销售预测、经营风险分析等
对于数据PBC和分析PBC而言，还需要数据编织（Data Fabric）技术的支持。
PBC与微服务的对比
下图是微服务的设计原则：
可以看出，PBC与微服务十分相似，甚至有似是而非之感。例如，它们都以API或Event作为对外通道，它们都要求一定的独立性和自治性，它们也都是去中心化的，同时，它们的粒度也不曾有大家公认的客观标准。然而，二者又有本质上的区别。微服务是一种架构风格，PBC更突出它作为一种构建块（building block），其目的是为了打造组合式应用。因此，可以理解为PBC是一种抽象概念，微服务则只是PBC的其中一种实现罢了。应用现代化方法体系中的开放能力，可以认为就是PBC。所以，PBC和微服务可以形成如下图所示的关系：
左图，一个促销微服务构成了一个PBC，右图，购物车和订单两个微服务构成了一个PBC。
PBC的实现
从满足PBC设计要素来思考PBC该如何设计。一个典型的PBC如下图所示：
一个完整的PBC需要：
- endpoints：提供可访问的端点，通过它满足PBC的发现能力，包括：
oaddress：可访问的地址，地址的类型与格式取决于绑定的类型obinding：描述通信协议、编码和必要的安全要求ostate：能力的当前状态，如released，running等
- contracts：定义对外公开的协议，通过它满足PBC的开放能力，包括：
ointerface：接口定义，接口类型可以为API、Event或Functionomessage：对通信消息的定义oversion：版本
- addon：插件，通过它满足PBC的扩展能力
- data：数据，通过它满足PBC的自治能力，它又可分为
ometadata：描述能力的元数据和支持代码生成的元数据信息obusiness data：业务数据oconfig：必要的配置信息
PBC的组合
PBC的组合方式包括：
- 编制（orchestration）：通过一个可执行的流程来协同内部及外部的能力交互，通过流程来控制总体的目标、涉及的操作、调用顺序。
- 编排（choreography）：通过消息的交互序列来控制各个能力之间的交互，参与交互的能力是对等的，没有集中的控制
这两种组合方式与微服务的组合方式完全相同。
现代化的三种途经
PBC是应用现代化的重要架构单元，通过它可以推动企业应用架构的现代化。根据不同IT生态和业务场景，运用PBC进行现代化可以有如下图所示的三种形式：
- 独立实现（Standalone Implementation）：这一方式可以针对数字化创新业务，在打造现代应用时，直接采用PBC模式，打造组合式应用；如果针对旧有系统的数字化转型，则通过直接替代的方式实现现代化。替代的内容可以是局部，也可以是整体。
- 遗留现代化（Legacy Modernization）: 这一方式主要针对旧有系统的数字化转型，可以识别大型遗留系统中哪些需要优化和调整，然后对这部分内容进行重构和升级，定义为PBC。
- 系统增强（System Enhancement）：对已有系统的现有功能不做任何变化，但对于该系统的扩展业务，则可以引入PBC，形成对该系统的功能增强。
应用架构的变化
由PBC构成的应用架构与传统方式的应用架构存在较大差别，如下图所示：
每个PBC具有独立完整的自治能力，形成为自治且可组合的架构单元。每个PBC的边界隔离了内外，内部的实现可以保持自己的个性，包括内部的技术栈、发布周期，都是完全独立的。PBC的开放、发现又保证了它的复用性与组合性，使得团队可以根据不同的应用场景对PBC进行组合。同时，利用网格能力，将PBC之间的协作实现及其对应的基础设施隔离出来，交由统一的运维团队。以PBC打造的应用架构是应用现代化提倡的现代应用架构，这种现代架构体现为面貌焕然一新的架构风格，可以认为是架构发展的趋势。
Cell-based Architecture
由于PBC的发现、开放、扩展和自治特性，它与传统乐高式的组件并不相同。组件的价值主要体现在复用能力上，每个组件并没有体现相对完整的业务价值，同时，它也不具有生命周期的独立性，不管是它的编译、运行，都是与组合后的应用绑定在一起的；PBC则不然，它是可以独立部署的，甚至可以独立售卖，通过定义标准契约，又能满足其开放性与组合性，使得PBC既可分，又可合，成为一种构成整个应用生态的细胞单元。当我们将PBC作为细胞单元，还将赋予它生命力，使其具有自组织、自学习、自迭代的进化特征，而这种可以快速拼装的Cell 应用则是敏捷创新的结果和进一步迭代的驱动。
API-centric Architecture
在现代应用架构中，体现业务价值的细胞单元——PBC，既可以独立向往提供业务能力，也可以彼此组合起来，对外提供更强大的业务能力。无论是PBC之间的组合，还是对外发布的能力，都通过混合型的APIs完成。对于前者，APIs提供集成能力，它就像胶水一样，将彼此完全独立的PBC集成起来；对于后者，APIs提供开放能力，它是PBC连通外界的通道，不断输出应用价值和数据价值。因此，在由PBC构成的现代应用架构中，APIs不可避免将成为架构的中心，并通过它体现PBC的“用”。PBC的APIs虽然可以是服务接口、事件通道或者函数（此之谓混合型APIs），但它们都必须遵循以下设计要求：
- 可用性：APIs的设计要从消费的角度考虑，尽可能降低调用的复杂度，让调用者愿意调用
- 可发现性：调用者可以快速获得APIs的信息，知道它在哪里，该怎么调用
- 标准：APIs的设计需要遵循统一的标准，如此才能满足PBC的可复用和可组合
- 可演进：APIs可以不断演进，但在演进的同时，需要考虑集成之间的兼容性，将变化带来的影响降到最低
- 安全：每个API都必须是安全的，当然，位于不同层次不同业务场景，对API安全性的要求与强度可以不同
细胞单元与API为中心的架构可以支持去中心化的大规模敏捷性组织和社群。
组织模式的变化
Gartner认为，应通过融合团队（fusion team）打造组合式应用（Composable Application），从而满足快速业务发展的要求。融合团队如下图所示：
无论是业务团队还是IT团队，都无法单独支持正在加速的业务变革步伐。业务团队和IT团队必须共同努力，分享共同的愿景，从而组建一个由业务角色和技术角色共同构成的融合团队。融合团队打通了业务和技术之间的壁垒，并在统一语言的指导下，形成领域知识的共享。如此就可以更好地以业务结果为共同目标，推动业务快速适应变化并快速创新。融合团队定义的三种角色，参与构建PBC的不同方面：
- 技术专家（Technical Professional）：负责设计PBC的接口，并通过开发或平台实现一个满足业务价值的PBC，在构建时，它需要与业务专家沟通和协作
- 业务专家（Business Professional）：PBC的调用者，也是PBC的需求提出者，也可以是PBC的购买者
- 业务技术人员（Business Technologist）：PBC的组装者，可以利用平台或胶水代码，完成对PBC的组合，对外输出完整的业务能力
每个融合团队可以是位于企业内部打通部门墙的联合团队，也可以是不断涌现的微创业者社群，以开放的协作共创方式完成对创新应用的构建。这种去中心化的团队组织模式恰好与去中心化的由PBC构成的细胞单元架构保持一致，符合康威定律的定义。
参考资料
- 《What are Packaged Business Capabilities?》（https://www.elasticpath.com/blog/what-are-packaged-business-capablities）
- 《3 APPROACHES TO PACKAGED BUSINESS CAPABILITIES》（https://www.govloop.com/community/blog/3-approaches-to-packaged-business-capabilities/）
- 《如何做好组装式应用》（https://cloud.tencent.com/developer/article/2192796）
- 《对话Gartner孙鑫：解密数字化新玩法—组装式企业》（https://mp.weixin.qq.com/s/5YfI8DNjsAlFN3y2QbGKsQ）
- Gartner《Top Strategic Technology Trends for 2022》
