写在前面
ThoughtWorks每年都会出品两期技术雷达，这是一份关于科技行业的技术趋势报告，在四个象限：技术、平台、工具以及语言和框架对每一个条目（Blip）做采用、试验、评估、暂缓的建议。（参考阅读：解读技术雷达的正确姿势）
一直以来，我们都未对每一个Blip做进一步的解读，而这次决定尝试一个新的专栏——《雷达哔哔哔》，由作者根据自己实践与理解，对雷达中部分条目作出解析，致力于用一篇篇短小精悍的文字，帮助读者加深对雷达的理解。
今天是《雷达哔哔哔》的第三篇，依然关注架构，Blip是ArchUnit。
位置
2018年11月第19期技术雷达，工具象限，建议试验
目标受众：
系统架构师，技术管理者，开发人员
关注问题：
- 如何在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和演进式架构来促进架构对于业务的匹配度和适应度；还是截然相反的错误地滥用这种能力成为所谓的管理手段或是技术上的噱头，最终导致系统架构僵化，无法支撑业务需要，决定权还是在我们架构师手中。
不要过度神话工具，也不要让工具替我们背锅，工具只是工具，工具本身没有对错。
工具：
延展阅读：
👇👇👇订阅最新期技术雷达
