ArchUnit：如何强制实现单一消费者依赖规则

本教程将深入探讨如何使用archunit定义和强制执行复杂的架构规则，特别是确保特定类型的类（如repository）只能被单一消费者类（如service）依赖。我们将通过两种方法，包括利用`describedpredicate`的简洁实现和自定义`archcondition`以生成更详细的违规消息，来演示如何精准控制类之间的依赖关系，从而维护清晰且可预测的系统架构。

引言：架构规则与ArchUnit

在软件开发中，维护清晰的架构边界至关重要。ArchUnit是一个强大的Java库，它允许开发者通过编写单元测试来验证和强制执行代码库的架构规则。这有助于在早期阶段发现潜在的架构违规，防止技术债的积累。

本文将聚焦于一个具体的架构挑战：如何确保某些核心组件（例如数据访问层中的Repository类）只能被单一的消费者组件（例如业务逻辑层中的Service类）所依赖。这意味着一个Service可以依赖多个Repository，但一个Repository绝不能被多个Service共享。

初始规则与限制

首先，我们可能已经定义了一个基础规则，确保Repository类只被Service类所依赖。这可以通过以下ArchUnit规则实现：

import com.tngtech.archunit.lang.ArchRule;
import static com.tngtech.archunit.lang.syntax.ArchRuleDefinition.classes;
import com.tngtech.archunit.junit.ArchTest;

// 假设 SUBPACKAGE_NAME_REPOSITORY 和 SUBPACKAGE_NAME_SERVICE 已定义
// 例如:
// private static final String SUBPACKAGE_NAME_REPOSITORY = "..repository..";
// private static final String SUBPACKAGE_NAME_SERVICE = "..service..";

@ArchTest
static final ArchRule repository_must_only_be_used_by_a_service =
        classes().that().resideInAnyPackage(SUBPACKAGE_NAME_REPOSITORY)
                 .should().onlyHaveDependentClassesThat()
                 .resideInAnyPackage(SUBPACKAGE_NAME_SERVICE);

这条规则确保了Repository的依赖者必须是Service包中的类。然而，它并未解决核心问题：如何限制一个Repository只能被一个Service依赖。它只检查了依赖者的类型，而不是数量。为了实现“单一消费者”的约束，我们需要更复杂的条件。

使用自定义ArchCondition实现单一消费者规则

ArchUnit提供了ArchCondition接口，允许我们定义高度定制化的规则检查逻辑。通过实现这个接口，我们可以访问类的详细依赖信息，并根据这些信息来判断是否满足规则。

方法一：简洁的DescribedPredicate实现

对于相对简单的条件，可以使用DescribedPredicate结合ArchConditions.have来快速实现。这种方法代码量少，但生成的违规消息可能不够详细。

VFitter

VFitter是一个为自由职业者、组织和品牌打造的AI协作平台

下载

import com.tngtech.archunit.core.domain.JavaClass;
import com.tngtech.archunit.core.domain.Dependency;
import com.tngtech.archunit.lang.ArchRule;
import com.tngtech.archunit.junit.ArchTest;

import static com.tngtech.archunit.base.DescribedPredicate.describe;
import static com.tngtech.archunit.lang.conditions.ArchConditions.have;
import static com.tngtech.archunit.lang.syntax.ArchRuleDefinition.classes;

@ArchTest
ArchRule repository_must_have_exactly_one_dependent_class =
    classes().that().resideInAnyPackage(SUBPACKAGE_NAME_REPOSITORY)
        .should(have(describe("#{dependent classes} == 1", javaClass ->
            javaClass.getDirectDependenciesToSelf().stream()
                .map(Dependency::getOriginClass).count() == 1
        )));

代码解析：

• classes().that().resideInAnyPackage(SUBPACKAGE_NAME_REPOSITORY)：选择所有位于Repository包中的类作为规则检查的目标。
• .should(have(...))：应用一个条件。
• describe("#{dependent classes} == 1", javaClass -> ...)：这是一个DescribedPredicate，它接收一个描述字符串（用于在报告中显示）和一个Lambda表达式。
• javaClass.getDirectDependenciesToSelf()：这是关键方法，它返回一个流，包含所有直接依赖于当前javaClass的Dependency对象。
• map(Dependency::getOriginClass)：从每个Dependency中提取出依赖方的JavaClass。
• count() == 1：计算依赖方的数量，并检查是否恰好为1。

优点： 代码简洁，易于理解。 缺点： 违规消息相对通用，只会显示“类X不满足条件：#dependent classes == 1”，无法具体指出是哪些Service依赖了它，或者根本没有Service依赖。

方法二：自定义ArchCondition以提供详细违规消息

为了获得更具诊断性的违规消息，我们可以直接实现ArchCondition接口。这允许我们在条件不满足时，构建包含更多上下文信息的错误消息。

import com.tngtech.archunit.core.domain.JavaClass;
import com.tngtech.archunit.core.domain.Dependency;
import com.tngtech.archunit.lang.ArchCondition;
import com.tngtech.archunit.lang.ArchRule;
import com.tngtech.archunit.lang.ConditionEvents;
import com.tngtech.archunit.junit.ArchTest;

import java.util.Set;
import static java.util.stream.Collectors.joining;
import static java.util.stream.Collectors.toSet;
import static com.tngtech.archunit.lang.ConditionEvent.createMessage;
import static com.tngtech.archunit.lang.SimpleConditionEvent.violated;
import static com.tngtech.archunit.lang.syntax.ArchRuleDefinition.classes;

@ArchTest
ArchRule repository_must_have_exactly_one_dependent_class_with_detail =
    classes().that().resideInAnyPackage(SUBPACKAGE_NAME_REPOSITORY)
        .should(new ArchCondition<JavaClass>("have one dependent class") {
            @Override
            public void check(JavaClass javaClass, ConditionEvents events) {
                Set<JavaClass> dependentClasses =
                    javaClass.getDirectDependenciesToSelf().stream()
                        .map(Dependency::getOriginClass)
                        .collect(toSet());

                if (dependentClasses.size() != 1) {
                    String message;
                    if (dependentClasses.isEmpty()) {
                        message = "has no dependent classes";
                    } else {
                        message = dependentClasses.stream()
                            .map(JavaClass::getName)
                            .collect(joining(", ", "has several dependent classes: ", ""));
                    }
                    events.add(violated(javaClass, createMessage(javaClass, message)));
                }
            }
        });

代码解析：

• new ArchCondition<JavaClass>("have one dependent class")：创建一个匿名内部类实现ArchCondition，并提供一个描述字符串。
• @Override public void check(JavaClass javaClass, ConditionEvents events)：这是核心方法，ArchUnit会为每个被检查的类调用它。
• Set<JavaClass> dependentClasses = ... .collect(toSet())：与方法一类似，收集所有直接依赖于当前javaClass的类。使用Set可以自动去重。
• if (dependentClasses.size() != 1)：检查依赖者数量是否不等于1。
• String message; if (dependentClasses.isEmpty()) { ... } else { ... }：根据依赖者的数量构建不同的违规消息：
  • 如果dependentClasses为空，则表示没有Service依赖这个Repository。
  • 如果dependentClasses包含多个类，则列出所有依赖方的全限定名，清晰地指出哪些Service违反了规则。
• events.add(violated(javaClass, createMessage(javaClass, message)))：当条件不满足时，通过ConditionEvents对象报告违规。violated方法用于标记违规，createMessage用于生成带有类名和自定义描述的完整消息。

优点： 提供了高度定制化的、具有诊断性的违规消息，这对于理解问题根源和修复架构违规非常有帮助。 缺点： 代码量相对增加，需要对ArchCondition接口有更深入的理解。

总结与最佳实践

通过上述两种方法，我们成功地使用ArchUnit实现了“一个Repository只能被一个Service依赖”的架构规则。

• 选择合适的实现方式： 如果你追求简洁，且默认的违规消息足够，可以使用DescribedPredicate。如果需要详细的诊断信息，自定义ArchCondition是更好的选择。在实际项目中，通常推荐使用自定义ArchCondition，因为它能显著提高架构违规报告的可读性和实用性。
• 清晰的包结构： 确保你的代码包结构清晰，如SUBPACKAGE_NAME_REPOSITORY和SUBPACKAGE_NAME_SERVICE的定义，这是ArchUnit规则能够有效工作的基础。
• 集成到构建流程： 将ArchUnit测试集成到你的CI/CD流程中，确保每次代码提交或构建时都能自动检查架构规则，从而在早期发现并解决问题。
• 持续维护： 架构规则并非一劳永逸。随着项目的发展，可能需要调整或添加新的规则。定期审查和更新ArchUnit测试是维护健康架构的关键。

ArchUnit为我们提供了一个强大的工具集，用于在代码层面强制执行架构原则。通过灵活运用其API，特别是ArchCondition，我们可以构建出满足项目特定需求的复杂架构规则，从而提升代码质量和可维护性。