• 支持架构规则自动化检查

• 轻量级，接入成本低

• 结果及时反馈

• 灵活扩展且扩展成本低

对于架构规则常见的验证方式：代码评审、代码质量分析工具或平台、Archunit

图1.对于架构规则常见的验证方式

以下对常见的几种方式进行优劣势对比：

代码评审：通过强流程控制代码评审活动发生，增强代码评审的强度和质量

• 不需要引入额外的技术，没有学习成本

• 灵活：通过人工评审方式可以覆盖架构约束更全面

• 非自动化方式执行，质量靠人工保证，人为因素存在较多不可控因素
• 代码评审范围越广，人力成本投入则越大

• 代码评审流程后置，不能及时反馈规则检测结果

代码质量分析工具：比如Sonar、Checkstyle等

• 成熟的工具或平台，内置开箱即用的规则

• 三方工具支持，不影响代码库结构

• 缺少灵活性，架构规则约束支持程度有限，不能很好地解决架构层面规则约束
• 强调代码质量分析结果，不能有效处理强制规则约束

• 定制规则有一定成本(因平台扩展能力而异)

Archunit：通过单元测试形式对架构规则自动化检查

• 支持丰富的架构约束规则定制能力，例如分层依赖规则、包依赖规则、循环依赖、继承关系约束等
• 虽然以单测代码方式体现，但不影响主业务开发，可以通过增量方式引入，逐步增强应用的架构约束能力
• Archunit 提供的 Java 流式API 易于理解，接入和使用成本低

• 使用纯Java单测框架以单元测试形式自动化执行，及时反馈单测结果

• 需要额外编写单元测试代码，增加了一部分工作量

• 引入了新的类库有一定学习成本

• 循环依赖

• 包的包含关系

• 类的依赖关系

• 类和包的包含关系

• 继承关系

• 注解

Archunit和代码质量分析工具的关系如下图所示，二者都可以对代码进行分析，在功能覆盖上存在一定交叉。

使用Archunit编写架构规则约束非常简单，其提供了便捷的流式API，可以快速的构建规则。

图4.RULE.01 所有的枚举类必须以Enum为后缀

图5.对应用分层进行约束校验

图6.在IDE下执行Archiunit单元测试结果示意

架构规则组织可以从多个维度，比如：

图7.左侧：基于逻辑分类进行分组；右侧：基于职能分类进行分组

团队是否要引入Archunit本身也是一项架构决策，建议采用文档化形式对该决策进行记录，记录形式参考《轻量级架构决策记录机制》https://developer.jdcloud.com/article/2646?mid=30

图8.准备-试点-优化-推广的模式

实施准备：

• 从规范复用的角度考虑，团队需要定义统一的开发规范，包括但不限于编码规范、异常规范、命名规范、依赖规范等等，并在团队内达成一致。建议采用统一的、文档化的形式进行记录（比如，在线表格系统）。对于每条开发规则建议增加比如 “正例”、“反例”、“规则描述”、“规则详细说明”、“是否可自动实现” 等维度描述信息
• 基于Archunit实现通用架构约束以便在不同项目间进行复用

应用试点：在产品线内部选定一个试点应用

复盘优化：基于试点效果进行复盘，基于团队成员反馈进行架构规则优化、已有规则的修改及废弃等等

推广普及：基于试点的一些实践在其它应用或业务线进行推广普及

Archunit不能做什么：

• 处理文件
• 测试所有架构属性
• 只支持JVM语言
• SOURCE注解
• 需要导入大量代码，加入CICD流水线后的时长影响

• 不能保证自身的维护性

Archunit对架构约束的自动化检测极有价值，且具有较低的接入和定制化成本，强烈建议团队引入试点。引入Archunit进行架构约束自动化检查后，将对以下方面产生影响：

• 有助于降低系统架构腐化，提升系统可维护性
• 新类库引入有一定的学习成本
• 代码评审活动增加一项活动：执行架构约束单元测试
• 开发成员日常开发中需要持续执行并关注架构约束单测结果，并确保测试通过