云巧组件定义
云巧组件可以被定义为：预集成阿里云产品、按统一规范开发，包含独立而完整的业务逻辑的单元。
云巧组件构成
云巧组件由内部能力和外部集成两大分类构成。
内部能力
软件架构信息 |
内部服务调用关系、领域模型设计（DDD） |
软件版本信息 |
代码仓库与镜像仓库地址、打包代码版本和镜像版本 |
文档 |
功能介绍、适用场景等 |
质量 |
质量检测结果，包括：静态扫描/安全扫描结果、单元测试通过率和覆盖率、测试用例执行率、自动化测试覆盖情况等 |
数据 |
数据库表结构（DDL）、种子数据（Seed Data） |
元数据 |
资源定义、配置定义、流程数据、表单数据 |
外部集成
外部资源依赖 |
阿里云产品集成、外部接口/消息依赖 |
接口 |
对外API列表。自动发现并注册到云巧资产市场 |
消息 |
对外输出消息定义 |
数据交换 |
与外部数据源的数据交换 |
用户界面 |
页面名及URI清单，用于微前端页面装配 |
为什么需要云巧标准
心理学里有一个术语：非我所创综合症，也称为NIH综合症（英语：Not Invented Here Syndrome），指的是人们只是由于某种产品、研究成果或知识来源于其他地方就抵制的心理。在软件开发领域，非我所创综合症表现为不信任别人的成果，而宁愿重复造轮子。（甚至你可能都不一定信任自己3个月前开发的代码LOL。）而重复造轮子最终会走向低效重复建设。
对于同一个小组内，还可以通过互相代码评审、结对编程等方式来增强信任感。而云巧资产市场上目前已有300多个技术资产，其中大部分来自其他团队，甚至来自于其他合作伙伴公司。要抵抗这种心理倾向，使用户能信任“非我所创”的组件，这就对组件提出了更高的要求。
云巧组件标准
云巧组件标准的理论支撑
对在2022年12大战略趋势中的组装式应用，Gartner将其具体落地拆解为4个维度：
- 编排
- 模块化
- 发现
- 自主性
- 模块化：模块化是可组装的关键。无论是规划应用、组织还是业务模型。组成整个系统的每个组件都必须是具有独立而完整业务逻辑的单元。业务单元的粒度十分重要，太大不足以提高开发过程的敏捷，太小又无法保证组件内业务的完整性。
- （可）发现：组件开发出来后，是否能让交付团队快速找到？组件的文档是否足够清晰和完整，能让交付团队准确评估适用性？可发现的高级要求包含了组件的运维特性，包括资源和性能等。
- 自治（自主性）：每个交付项目都有其特殊性，经常会根据客户要求或现实限制，只选配少部分组件，或将组件替换成其他外部系统。自治意味着组件能不强依赖其他组件独立运作，并在被替换时具有最小的改造负担。
- （可）编排：基础的可编排需要支持业界通用协议，不限于特定编程语言。可编排还体现在支持观测和跟踪、安全、支持DevOps等能力。
六大维度：ACCORD
可组装式应用的理论，结合了云原生的理念和交付质量要求，云巧对云巧组件设计了六大维度的标准。根据这六大维度名称的英文首字母组成单词ACCORD：
- Autonomous（自治）
- 关键字：封装
- 组件封装良好，最小化组件间的依赖，只暴露必要的公开接口和公共方法，隔离需求变更带来的影响。对应Gartner4个维度中的“自主性”。
- Cloud Native（云原生）
- 关键字：弹性、自动化
- 符合云原生最佳实践，支持容器化部署与弹性运维。参考The Twelve-Factor App。
- Cataloged（可发现）
- 关键字：易用
- 具有良好自我描述能力，易于在一个统一的市场里被找到和评估适用性。对应Gartner4个维度中的“发现”。
- Orchestrated（可编排）：
- 关键字：被集成
- 可以被放心地集成，可观测，设计风格统一。对应Gartner4个维度中的“编排”。
- Robust（健壮）
- 关键字：安全、质量
- 质量保障，符合安全标准，易维护，易扩展。
- Domain Driven（领域驱动）
- 关键字：边界
- 领域驱动设计，具备明确的业务价值与清晰的边界划分。对应Gartner4个维度中的“模块化”。
通过ACCORD云巧组件标准对沉淀的云巧组件加以持续的约束，可以保证组件在更大范围内的互通与互信。符合标准的组件也能以统一的体验去被复用、集成、部署。
云巧组件的红线：合规
违反合规要求会对阿里和生态合作伙伴公司带来严重的法务风险，造成不可控的经济和声誉损失。所以保证组件的合规是红线要求。
合规主要包含以下三个方面：
- 知识产权合规：阿里自有知识产权的组件由阿里侧负责合规材料，ISV自有知识产权的组件需由ISV提供软著（计算机软件著作权证明材料）
- 源代码及数据合规：源代码及演示环境数据不包含敏感信息（客户/其他交付项目信息等）
- 内容合规：文档不包含敏感信息（客户/其他交付项目信息等）
云巧标准的度量
为什么需要对标准进行度量
光靠云巧资产市场的开发人力，必然无法对每个组件的每个版本更新进行代码评审。但是否我们就此束手无策了？一切业务数字化，我们可以：
- 制定组件标准
- 将标准自动化度量
- 度量结果实时生成综合了多个维度的度量指标
通过指标，一方面可以将组件的信息对适使用方透明化，增强信任感；另一方面也为组件owner明确组件优化方向。
云巧成熟度指标
通过对云巧组件各维度的实现程度加权评分，可以度量出其所处的成熟度，以“云巧成熟度指标”的形式展现在资产市场上。
对于支持自动检查的检查项，会进行自动打分；对于目前尚不支持自动检查的检查项，会在组件首次上传和后续每次大版本更新时，由云巧资产市场的平台管理员评分。
对于组件开发者，可以将成熟度指标作为进一步打磨和优化组件的方向参考；
对于组件使用者，可以将成熟度指标作为选择组件的参考依据。
自治的度量
维度 |
目标 |
说明 |
自治 |
接口定义清晰 |
|
只暴露必要的公开接口和公共方法 |
不直接对外暴露领域层或数据模型层 |
|
组件间不共用数据库 |
||
环境变量预定义 |
||
数据自包含 |
将数据和元数据（流程和表单定义）封装在组件内部。 推荐使用数据库管理工具 |
|
无第三方服务依赖 |
对依赖的外部第三方服务已mock。 |
云原生的度量
维度 |
目标 |
说明 |
云原生 |
可构建镜像 |
支持容器化部署的必要条件之一 |
应用无状态 |
影响水平伸缩，如写本地文件、采用本地缓存、本地会话状态等 |
|
应用启动时间短 |
||
支持健康检查机制 |
可发现的度量
维度 |
目标 |
说明 |
可发现 |
可演示 |
有可稳定访问的演示环境（可借助云巧工坊搭建） |
关键可发现信息 |
组件文档中“组件SOW”、“依赖云资源”、“API/SDK文档”部分不为空 |
|
明确业务价值 |
组件文档中“业务价值”部分不为空 |
|
明确架构 |
组件文档中“架构图”部分不为空 |
|
明确性能设计 |
组件文档中“性能设计”部分不为空 |
|
明确测试报告 |
组件文档中“测试报告”部分不为空 |
可编排的度量
维度 |
目标 |
说明 |
可编排 |
接口定义使用版本隔离机制 |
|
支持常见协议 |
如RESTFUL、RPC、消息等 |
|
接口支持向后兼容 |
||
前端性能在阈值范围 |
避免前端响应时间超长 |
|
接口幂等 |
支持重试机制，做幂等控制 |
|
遵循统一设计风格 |
推荐使用B-Design设计 |
|
可观测 |
支持调用链跟踪、日志信息规范 |
|
支持微前端 |
健壮的度量
维度 |
目标 |
说明 |
健壮 |
知识产权合规 |
对ISV自有知识产权组件已提供软著 |
源代码、内容及数据抽象 |
源代码、文档及演示环境数据不包含未抽象脱敏的信息（包括但不限于客户/其他交付项目信息等） |
|
无敏感信息 |
源代码、文档及演示环境数据不包含敏感信息（密码、AKSK等） |
|
敏感信息加密存储 |
||
通过静态代码扫描 |
不存在高危级别的静态代码扫描问题 中危静态代码扫描问题密度可控 |
|
通过安全扫描 |
不存在高危级别的安全扫描问题 中危安全扫描问题密度可控 |
|
通过敏感信息扫描 |
不存在高危级别的敏感信息扫描问题 中危敏感信息扫描问题密度可控 |
|
单元测试覆盖 |
达成可满足质量保障要求的单元测试覆盖率和通过率 |
|
冗余代码少 |
重复冗余代码密度低 |
|
易于维护 |
高圈复杂度密度低 |
|
代码坏味道少 |
模块化的度量
维度 |
目标 |
说明 |
模块化 |
领域驱动设计 |
按照DDD（Domain-driven design，领域驱动设计）的理念维护了该组件的领域模型。 应用领域驱动设计实体、值对象设计了界限上下文和领域蓝图等。 |
无循环依赖 |
组件间不存在循环依赖 |
|
领域模型维护质量 |
不存在独立的领域模型层。 领域模型在代码中可见 |
云巧标准的分档
标准的每个规则有一个重要等级。总共分为4个档位：BLOCKER、CRITICAL、MAJOR、MINOR：
- BLOCKER的为红线，代码存在敏感信息，严重的安全漏洞等。如果存在，不允许发布。
- CRITICAL为较严重的质量或安全问题。如果存在，需要人工审核才能发布。
- MAJOR为影响效率和质量的问题。建议重构，不影响发布。
- MINOR为需优化的问题，可能会影响到易用性和可维护性。建议重构，不影响发布。
举例来说，“健壮”维度中的“知识产权合规”的重要等级就是BLOCKER级别的，必须完成修改才能上架。
我们在云巧资产市场和云巧工坊已经实现了上述部分标准的度量。后续也会不断进一步丰富可度量的标准。
即使所有的严重的问题都修复了，成熟度还是能够指导持续改进，精益求精。没有严重问题的是合格，而合格更上一层的标准就是云巧认证。
云巧认证
在每个时间周期（暂定自然季度）结束时，由阿里侧技术和业务专家组成的云巧评审委员会，对云巧资产市场上的所有组件进行全方位的评分。对于满足一定阈值的云巧成熟度指标得分的组件，综合评估组件业务价值后，授予“云巧认证”。云巧认证是云巧评审委员会对组件可信任度的最高评价。
云巧评审委员会承诺：
- 公正品宣：基于统一的云巧成熟度指标为入围标准，不会对阿里或其他ISV设定双重标准
- 专业权威：评审委员会由不同领域的专家组成，保证评审结果的权威性
云巧标准的实践
新开发应用如何遵循标准
新开发的应用可以借云巧工坊的标准流程，打造符合标准的云巧组件。
更多参见云巧工坊简介。
已交付项目代码如何按照标准沉淀组件/交付模板
对于已交付项目的代码，通常执行步骤如下：
- 划分通用技术部分和业务部分：通用技术部分可直接复用云巧基础技术平台交付模板，只需要针对业务部分评估是否沉淀
- 将业务部分的应用沉淀到云巧工坊
- 合规改造
- 通过领域驱动设计，划分业务边界
- 定义需要组件需要对外暴露的API
- 进行代码静态扫描、敏感信息扫描、安全扫描，修复扫描出的高危漏洞
- 补完单元测试用例
- 云原生改造
- 按结构化文档标准补完文档
