ArchUnit

写在前面

ThoughtWorks每年都会出品两期技术雷达，这是一份关于科技行业的技术趋势报告，在四个象限：技术、平台、 工具 以及语言和框架对每一个条目（Blip）做采用、试验、评估、暂缓的建议。（参考阅读： 解读技术雷达的正确姿势 ）

一直以来，我们都未对每一个Blip做进一步的解读，而这次决定尝试一个新的专栏——《雷达哔哔哔》，由作者根据自己实践与理解，对雷达中部分条目作出解析，致力于用一篇篇短小精悍的文字，帮助读者加深对雷达的理解。

今天是《雷达哔哔哔》的第三篇，依然关注架构，Blip是 ArchUnit 。

位置

2018年11月第19期技术雷达， 工具 象限，建议 试验

目标受众：

系统架构师，技术管理者，开发设计人员

关注问题：

• 如何在 Java 系统架构下，应用架构适应度函数（Architectural fitness function）来驱动架构演进？
• 如何在Java系统架构下，做系统演进后架构守护，减缓系统腐化？

解读：

在上一期我们介绍了 架构适应度函数（Architectural fitness function） ，也提到了ArchUnit，这期就来详细介绍一下。

ARCHUNIT是用来检查架构特征的Java测试库，比如包与类的依赖关系、注解验证、甚至层级一致性。它可以在你现有的测试方案中，以单元测试的方式运行，但目前只能用于Java架构。

ArchUnit测试套件可以合并到C(I 持续集成)环境或部署流水线，使我们很容易地以演进式架构的方式实现适应度函数。我们来看看ArchUnit都能做些什么：

• Package Dependency Checks

• Class Dependency Checks

• Class and Package Containment Checks

• Inheritance Checks

• Annotation Checks

• Layer Checks

• Cycle Checks

想要了解更多，可以移步 【官方用户指南】

最后不得不说一下，架构优劣不取决于是否遵循某一个标准，而是应该取决于能否支撑业务的需要。约束越强，灵活度越低，架构就会越加僵硬，缺少适应性，产生冗余。

所以工具本身只是赋予了我们约束架构的能力。但是能否正确地使用这种能力通过Fitness Function和演进式架构来促进架构对于业务的匹配度和适应度；还是截然相反的错误地滥用这种能力成为所谓的管理手段或是技术上的噱头，最终导致系统架构僵化，无法支撑业务需要，决定权还是在我们架构师手中。

不要过度神话工具，也不要让工具替我们背锅，工具只是工具，工具本身没有对错。

工具：

ArchUnit

延展阅读：

ArchUnit | Technology Radar | ThoughtWorks

雷达哔哔哔 – Architectural fitness function

订阅最新期技术雷达