雷达描述：
ArchUnit是一个基于 Java 的测试库，用于检查代码的结构特性，如包和类的依赖关系、注解验证，甚至还能检查代码分层是否一致。我们很喜欢 ArchUnit 的地方是，它可以在现有的测试环境中以单元测试的方式运行，尽管只支持基于 Java 的架构。在CI环境或部署流水线中集成ArchUnit 测试套件，可以方便地在演进式架构中实现架构适应度函数。
位置
2018年11月第19期技术雷达（11.14正式发布，文末可订阅），工具象限，建议试验
目标受众：
系统架构师，技术管理者，开发人员
关注问题：
- 如何在Java系统架构下，应用架构适应度函数（Architectural fitness function）来驱动架构演进？
- 如何在Java系统架构下，做系统演进后架构守护，减缓系统再次腐化？
解读：
在上一期我们介绍了架构适应度函数（Architectural fitness function），也提到了ArchUnit，这期就来详细介绍一下。
ArchUnit是用来检查架构特征的Java测试库，比如包与类的依赖关系、注解、甚至是调用层级一致性。它可以附加在现有的测试方案中，以单元测试的方式运行，但目前只能用于Java架构。
ArchUnit测试套件可以合并到持续集成环境及部署流水线中，使我们可以更容易地利用架构适应度函数实现演进式架构。我们来看看ArchUnit都能做些什么：
- Package Dependency Checks
- Class Dependency Checks
- Class and Package Containment Checks
- Inheritance Checks
- Annotation Checks
- Layer Checks
- Cycle Checks
想要了解更多，可以移步【官方用户指南】
最后不得不说一下，架构优劣不取决于是否遵循某一个标准，而是应该取决于能否支撑业务的需要。约束越强，灵活度越低，架构就会越加僵硬，缺少适应性，产生冗余。
所以工具本身只是赋予了我们约束架构的能力。但是能否正确地使用这种能力通过Fitness Function和演进式架构来促进架构对于业务的匹配度和适应度；还是截然相反的错误地滥用这种能力成为所谓的管理手段或是技术上的噱头，最终导致系统架构僵化，无法支撑业务需要，决定权还是在我们架构师手中。
不要过度神话工具，也不要让工具替我们背锅，工具只是工具，工具本身没有对错。
工具：
ArchUnit
