实战Arch Unit

在以前的文章中介绍了通过 《实战PMD》、《实战Checkstyle》在代码级守护我们的代码，比通过《实战Jacoco》来了解当前项目的测试覆盖情况。通过得到数据了解我们的项目质量，进行定向的改进。

使用这些简单方面的自动化工具比凭空猜想或者全靠人力来接发现代码上的问题，效率高多了。

这篇文章将聚焦在Arch Unit上，Arch Unit能通过为我们提供架构的守护。

1. 开发前的准备

2. 项目分层检测

3. 循环依赖检测（同一个package下，不同package下的循环依赖）

4. Package依赖检测

5. Package和Class的包含关系检测

6. 忽略某些违规行为的三种凡是

7. 如何组织Arch Unit的测试

先来看一下Arch Unit的相关功能介绍。

这些功能很好，但是要是面面俱到，那么维护、查看规则也是一件麻烦事，所以针对项目情况，有选择定制，才能更好的展现器价值。

通过自己坐在项目的情况，可以通过金字塔来罗列：哪些行为做了价值大，哪些事情做了价值小。

---

1，开发前的准备

Arch Unit集成了Junit4和Junit5，在它的模块中包含：archunit、archunit-junit4、archunit-junit5-api、archunit-junit5-engine、archunit-junit5-engine-api。

在项目中只需要引入测试相关的JUnit5相关的依赖。

dependencies {
    testCompile 'com.tngtech.archunit:archunit-junit5:0.13.1'
}

test {
    useJUnitPlatform()
}

实践过程中有可能遇到的情况：

Tips 01: 当 @Analysis 中配置的 package 目录写错时，并不会报错package不存在，而是会让全部测试通过。

Tips 02: *在 layer 验证的时候，定义 layer的时候，package 名称需要根据需要在包名后添加 “…”，例如：

layeredArchecture()
.layer("Representation").definedBy("com.page.practice.representation..")
.layer("Domain").definedBy("com.page.practice.domain..")
...

.whereLayer("Domain").mayOnlyAccessedByLayers("Representation")
...

其中的 com.page.practice.representation.. 结尾使用 ..，原因是 representation 中如果包含了其他两个package 例如：request 和 response，那么当 request 中调用到了 domain 中类后，上面的代码是可以检测通过。

如果去掉 com.page.practice.representation.. 结尾的 ..，那么当request 中调用到了 domain 时，检测是不过的。

---

2， 项目分层检测

在做DDD的一些落地项目中我们会使用四层架构，即Representation、Application、Domain、Infrastructure四层，这四层的调用关系如下图所示。

下面通过一个例子我们来约束这几层的调动关系。

package com.page.practice.archunit;

import com.tngtech.archunit.junit