写在前面的话
你可以从本文了解组装式开发的理念，以及阿里云GTS通过组装式理念交付项目的最佳实践：云巧。
如果你是阿里及阿里云生态合作伙伴的开发者，可以进一步访问云巧首页：https://gts.work/portal/yunqiao ，进一步了解云巧的能力。
即使你不是阿里及阿里云生态合作伙伴的开发者，也可以在自己的日常的开发过程中通过运用可组装式理念提升业务交付效率。我们总结了组装式应用的度量标准：云巧标准，包括了自治、云原生、可发现、可编排、健壮、模块化6个维度。你会发现其实很多开发者的开发过程中已经使用到了组装式开发的理念。你也可以回顾一下，看自己是否已经在不知不觉中运用了组装式理念进行开发？
前言
Gartner在2021年10月19日，正式发布了2022年重要战略趋势。其中包括了“可组装式应用”这一战略。在复杂多变的环境下，可组装式应用能提升企业的适应和创新能力。而企业要想实现可组装式的目标，Gartner提出了可组装能力指数，通过四个核心维度（模块化、原子性、可编排、可发现）来度量企业的技术和业务抽象能力。这四个维度是在原有的一些技术设计范式（解耦、微服务、事件驱动）和业务设计范式（领域模型驱动设计）之上的抽象和演进。同时Gartner也提出了一些最佳实践方面的建议，比如建设组件市场，帮助托管和发现组件；构建技术人员和业务人员混合组成的综合小组，来推进组件的建设。
看到可组装的时候，可能不少开发者不由自主想到的是：「可组装」不就是模块化吗？架构可组装（架构要分模块）不就是一句正确的废话吗？值得大费周章的又提出一个概念吗？如果你有类似的困惑，希望这篇文章可以让你对Gartner提出的「可组装」有个清晰的认识。
模块化编程的概念至少可以追溯到1968年。半个世纪的光阴，高级语言编程范式经历了过程式/结构化编程，面向对象编程，函数式编程；模块化从来都不是新的概念，可组装当然也不是。.NET世界甚至直白的将一个独立的可部署的逻辑单元叫做assembly。的确，你能说调用两个方法不是在组装吗？面向对象编程不是通过组装一堆对象完成功能吗？做技术架构的思想与编程的思想并无不同，你能说微服务架构就不是一个可组装的架构吗？因此你应该可以看得出来，如果没有清晰的定义，可组装就是怎么说都行，但却解决不了实际问题的假大空。
云巧是阿里云全球技术服务部团队，基于组装式交付理念，对定制化开发和交付提出的解决方案。我们会在下文先详细介绍组装式开发的理念，最后介绍云巧是如何将这个理念进行落地的。
被组装的单元
定义
为了澄清什么是我们所说的可组装，必须先清晰定义被我们组装的单元是什么。Gartner提出的组装的单元叫做PBC(Packaged Business Capability)。非正式的中文翻译叫做打包好的业务能力（在云巧中对应的概念叫做组件，后文将交替使用PBC和组件）。
Packaged business capabilities (PBCs) are software components that represent a well-defined business capability, functionally recognizable as such by a business user. Techically, 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.
-- Gartner ：《Innovation Insight for Composable Modularity Of Packaged Business Capabilities》
上面这一段包含了Gartner对于PBC的官方定义，也指出了一些PBC应该具备的重要特性。可以看到PBC是一个定义良好的，能够在功能上被用户识别的软件组件，也就是说一个做序列化的程序库叫做一个PBC是不合适的，因为用户（特意强调了业务用户，不是技术用户）感知不到序列化这件事情，但一个具有完整的购物车功能的小系统，就可以叫做一个PBC。
技术上来说，PBC是一个有边界的集合，这个集合的组成元素是数据schema，一堆的服务（注意并没有说一定得是微服务），API和事件通道。可以参见如下的模型：
需要澄清一下，虽然图上画成了六边形，并不代表一定是程序员所熟悉的六边形架构，不用六边形架构也能构建出可组装的PBC。
合格的PBC
一个良好实现（well-implemented）的PBC为了确保自治（没有重大外部依赖），应该是功能完备的。在判断一个组件是否合格（是否能被组装）时，可以参考企业可组装指数中提到的四个维度，模块化、可发现、自治、可编排；
要达到可组装的目标，需要组装平台（Composition Platform，即云巧资产市场的职责）和组件提供方一起努力，可组装指数中提到的四个维度，组装平台和组件提供方的职责在不同维度上有不同侧重，比如模块化和自治更多的需要组件提供方满足《云巧组件标准》，良好的设计和实现，组装平台仅能提供标准、约束、以及检查机制；而可发现和可编排，需要组装平台侧更多的投入，比如云巧构建资产市场来降低发现组件的成本，提供集成工作台来提高可编排的能力。这里我们站在组件的角度讨论单个组件的可组装能力，不讨论组装平台的职责。
模块化（Modularity）
模块化这个“古老”的概念，我们并不陌生，分离关注点（Separation of Concern）、信息隐藏（Information Hiding，也说封装，Encapsulation）等都是指导如何划分良好模块的方法，不在此赘述。此处想强调的是功能完整性（Functional Complete），在《云巧白皮书》提到过一个例子，我们在项目上实现Restful API的时候，出于成本考虑，我们可能不会完全实现一个资源的增删改查接口，只会实现业务需要用到的，但是为了提高可组装的能力，我们得都实现；另外一个例子是一个订单管理组件，在特定项目中我们可能只会做正向订单，但出于完整性考虑我们也会实现逆向订单。因此组件的功能完整性越高，其可组装性越强。
自治（Autonomy）
自治讲的是不干涉别国内政，自扫门前雪，你走资本主义路线还是社会主义路线我不管，你用Java实现还是Ruby on Rails实现，我也不管，在边界内部，你可以拥有自己的存储，自己的数据湖，去满足你自己的业务目标，都可以。
但是为了支持可组装，我们得支持开放的协议和标准，一个好的组件需要支持时下盛行（prevailing）的接口，比如当前流行Restful API，那最好实现它，之后如果GraphQL变得流行了，那也应该支持，不然可组装的能力就会降低。如果组件内有自己的数据仓库，如何进行数据共享也应该被考虑到。
自治的另一个需要关注的是边界，一个组件不会直接去查另一个组件的数据（OLAP的数据同步交换不在此列，因为不影响数据一致性），也不会直接去调用另外一个组件的内部方法，所以强化边界，也就起到了隔离变化的目的，这就像一个国家发生的骚乱，通过强化边防可以阻止其扩散到邻国，软件中可以用各种隔离手段来“强化边防”，也可以通过约定来达到，比如不要暴露内部服务等。
可发现（Discoverable）
组件提供者在可发现方面的努力可以分为两方面，静态的和动态的。静态的方面包括在资产市场（由云巧提供）注册，让别人能找到；提供友好，完善，高质量的文档，以供组装者进行详细的了解；提供演示环境，供人探索。动态的包括动态注册和发现，在Gartner的报告中有提到过可以通过动态的注册和发现组件来完成业务流程的动态编排和扩展。
可编排（Orchestrated）
在可编排方面，组件提供者应该尽可能的让自己的组件变得可编排，比如做好幂等控制（让编排的人不用担心组件参与的顺序，位置，重试机制等）、定义好清晰的接口、支持尽可能开放的集成方式、支持标准协议等等。
需要强调的是组件的大小也会影响编排的成本，就像微服务没有定义多小叫做微一样，可组装的概念并没有明确组件大小的标准，一个组件应该足够小，从而可被随时替换，但又应该足够大，包含完整的业务功能，同时也可降低维护和运维成本。
组件应该有UI吗？
从PBC的组成图中我们可以看到，UI是可选的，熟悉分层架构的同学都知道，越往上，越不稳定，UI的变化非常频繁，布局、颜色、流程、交互方式都会频繁发生变化，出于这个原因，组件是不推荐包含UI的。我们把不包含UI的组件叫做无头组件（Headless Component, Headless PBC)，无头组件通常是API-First的。但并不是说组件包含UI就毫无价值，较细粒度的UI是能够一定程度上应对展示层的变化的，却又不需要从头开始编写页面。
包含UI的组件在参与组装的过程中可能会提供不同的交互方式和风格，组装出来的应用的用户体验就会变得糟糕。
云巧为了解决这个问题，采用了阿里云企业级设计解决方案：BDesign。所有含UI的组件，都需要采用BDesign来实现。
事实上，组件除了可以有UI，组件还可以同时支持OLTP和OLAP，Gartner在谈PBC类型的时候也讲到过分析型的PBC，不在此赘述。
可组装单元的小结
有了定义，也知道了PBC的样貌，我们说的「可组装」就是通过组装一系列的PBC来开发企业应用程序。我们尝试来看看文章开始出的一些困惑：
- 所以先后调用两个方法是可组装吗？不是。
- 一堆对象合作完成一堆功能是可组装吗？视情况而定，得看被组装的对象是否能够代表一个PBC。
- 微服务架构就是可组装吗？视情况而定，得看微服务是否满足PBC的定义。
所以「可组装」不再是一个模棱两可的概念了。
组装过程
组装环境
了解了组装的单元后，接下来的问题就是怎么组装？就像玩乐高我们要么在地上，要么在一个大桌子上一样，我们得有一个场地来完成组装。
Gartner的实现可组装的Roadmap中回答了这个问题，Roadmap的第一步：识别组装者画像（Composer Persona），通俗讲就是我们需要了解组装的人，在不同的企业可能有不同的答案，组装者可能是不懂技术的业务人员，也可能程序员，程序员也分为初级的，或专家级的。因此Gartner给出了一些组装可能发生的地方：
- 开发框架 - 如果组装者是程序员，编排可以通过编写代码，比如在BFF（Backend for Frontend）中，前端应用中（例如可以为小组件前端封装React的Component，大组件可以利用微前端技术），或者Gartner提出的Mesh App（Gartner提出的MASA架构风格中的概念，可以简单理解成Web前端，移动端，IoT等设备）中，通过编写代码调用组件提供的API，即完成了编排。
- 集成框架 - 如果组装者是经验丰富的程序员，可以使用一些集成框架进行编排，比如Apache Camel, Spring Integration，Uber的开源框架cadence，云巧架构师组开发的arch-sketch-flow等。
- 页面搭建/表单搭建 - 如果组装者是不懂技术的业务人员，可以使用低代码或无代码平台进行编排，大多数低代码平台都支持调用外部API。在云巧也可以实现页面搭建和表单搭建。
云巧提供了云巧工坊，帮助你完成设计-开发-维护-上架的组件全生命周期的流程。你可以进行组装，你可以把多个组件的UI组装起来，变成一个前端系统，你也可以通过组装API完成特定的业务流程。但我们还是系统性的来分析下，我们可以在哪些地方进行组装，即编排的一系列活动。
云巧支持高度定制化，使用云巧，上述编排方式都支持，你只需要选择对于你来说最熟悉、最高效的方式，云巧也提供集成工作台，作为一个组装平台，让你可以在UI层面和API层面通过配置的方式进行组装。
没有最可组装，只有更可组装
在学习可组装的概念的时候，我一直在想，为什么软件可以被组装出来？代表着组件可以像乐高一样被扣在一起，一个组件有丁，另一个组件就得有卯。但是软件可不是乐高，并没有棱角，即使我们可以通过应用架构原则或约束，但不同的企业有不同的业务述求，个性化的需求多种多样，怎么能做到可以像搭乐高，搭积木一样来搭建适应不同企业的诉求的软件呢？除非你是复制一家企业，否则谈何容易。
Gartner确实提到：可组装不是一种架构风格，而是一种架构特性。也就是说可组装不是一个是或否的问题，我们能说你是否用了微服务架构，却不能说你是否用了可组装架构。我们永远可以通过提升可组装指数的四个维度，让架构变得更可组装，因此可组装指数可以指导我们为架构在可组装特性上进行打分，来衡量一个架构的可组装性。
设计自由
组件在可组装指数上做的足够好，足够标准了，就能像搭积木一样来构建企业的复杂软件了吗？答案是不行。想象一下，如果资产市场中总共只有2个组件，这两个组件从组件标准来讲，都可以得高分，但是我们能从这两个组件中组装出什么来呢？Gartner提出了一个叫做设计自由（Design Freedom）的概念，当组件数量足够多的时候，做业务设计的时候，就可以自由的选择适合自己的组件。在越多的人拥有沉淀和分享意识，资产市场就越丰富，我们就会拥有的更大的设计自由。
云巧落地实现组装式开发
云巧是阿里云从数千家企业数字化转型交付过程中孵化出来用于助力企业数字化转型落地实施的生产力工具平台。云巧平台通过组装式的方式开发业务应用系统，支持政企客户高度复杂行业应用系统高效率、低成本的定制化开发。云巧平台包括一系列可基于业务要求灵活组装的组件集与行业交付模板以及集成工作台，能够以统一的标准进行开发、部署、集成、数据交换及运维，政企客户可借助云巧已成型的业务组件及行业交付模板快捷、轻巧地完成应用系统定制化功能的组装和编排。
云巧由云巧组件、云巧资产市场、云巧生态和云巧工坊构成。
- 云巧组件为复用而生，每个组件由若干个微服务（前端、后端、移动端）组成，共同表达一个完整的业务逻辑单元，组件在部署形态上是相互独立的，并遵循统一的装配标准。云巧组件可以根据不同客户的需要，重新组合输出。并且它们按统一的标准开发，便于被不同伙伴的开发人员理解。
- 云巧资产市场是在云巧组件的基础上，面向开发者的云巧组件市场。在云巧资产市场市场中，我们把组件分为基础组件、通用组件、业务组件等几大类，并且给组件打上业务场景的标签，方便开发者检索并按需选配项目需要的组件。同时，伙伴可以借助我们提供的集成能力，从页面、API、消息、数据等多个维度，更快速地将组件与定制化开发的部分集成在一起，共同完成项目的系统交付。相较于打造平台型产品，可组装交付模式对组件的实施提出更高要求，尤其还要考虑与伙伴共建。所以我们原厂需要制定技术标准，并提供大量工具来辅助伙伴做到这一点。比如统一的工程脚手架、IDE插件、可视化的DDD（领域模型驱动）设计器等等。
- 云巧理念是“开放”。伙伴可以基于项目需要灵活选择组件，项目中的其他部分由伙伴定制化开发，最终把云巧组件和定制化开发部分集成起来，完成一个完整项目的交付。伙伴也可以在资产市场上传自己的组件。
- 云巧工坊是源自阿里云自身实践，覆盖云巧资产全生命周期的设计研发一体化平台，协助开发者打造符合云巧标准的技术资产。
阿里云正在通过与生态伙伴共同丰富资产市场，以支撑更广泛的政企客户业务应用系统组装式的定制开发。
云巧常见问题
Q：组装式开发和我有什么关系？
通过上文的介绍，你可以发现通过组装式开发，可以快速适应来自内部和外部的业务需求变化。Gartner的分析显示：“在不断变化的业务环境中，业务适应性需求能够引导企业转向支持快速、安全和高效应用变化的技术架构。可组装式应用架构增强了这种适应性，而采用可组装方法的企业机构在新功能的实现速度上将比竞争对手快80%。”
如果你是阿里及阿里云生态合作伙伴的开发者，可以进一步访问云巧首页：https://gts.work/portal/yunqiao ，进一步了解云巧的能力。
即使你不是阿里及阿里云生态合作伙伴的开发者，也可以在自己的日常的开发过程中通过运用可组装式理念，提升业务交付效率。
Q：我怎么可以访问云巧？
A：在当前阶段，云巧主要还是用于阿里云和生态合作伙伴的交付项目，暂未公开开放。如果你是阿里云生态合作伙伴的开发同学，可以在加入全球技术服务部组织后访问云巧首页。
即使对于非阿里云交付项目，你依然可以按照上文介绍的“组装式开发”的理念来进行开发，提升开发效率和质量。
Q：云巧是低代码/无代码平台么？
A：云巧不是低代码/无代码平台。
低代码/无代码平台通常最多只提供私有化部署，不会开放底层引擎源代码。
相比低代码/无代码平台，云巧有两个明显的优势：
- 可对所有源码进行定制开发
- 支持提供所有源代码的交付形式
Q：云巧帮我解决哪些重要的问题？
对客户：提升交付速度，提高交付质量，降低用工成本
对阿里云：
- 沉淀大量实用的行业组件，让人人都成为产业开发者
- 云巧统一了阿里云交付项目技术栈，提升技术可控性
对生态伙伴：快速提升人员能力；拓宽拓深行业赛道；构建大型项目交付能力。
