ArchUnit规则：确保Repository类仅被单个Service类依赖-java教程-PHP中文网

ArchUnit规则：确保Repository类仅被单个Service类依赖

本文深入探讨了如何利用archunit在java项目中实施严格的架构规则，特别是如何确保特定类型的类（如repository）只能被另一个特定类型的类（如service）精确地依赖一次。通过定义自定义`archcondition`，我们不仅能准确地检查依赖关系的数量，还能生成详细且富有洞察力的违规报告，从而有效地维护和加强代码库的架构一致性。

ArchUnit简介与架构约束需求

在软件开发中，维护清晰的架构边界和依赖关系至关重要。ArchUnit是一个强大的Java库，它允许开发者通过编写单元测试来验证和强制执行这些架构规则。一个常见的架构模式是分层架构，其中数据访问层（Repository）由业务逻辑层（Service）调用。有时，我们可能希望强制执行一个更严格的规则：一个特定的Repository实例或Repository类，只能被一个Service类所依赖。这有助于防止Repository被不当共享，从而提高模块的内聚性并降低耦合度。

假设我们有以下需求：

Service类可以依赖任意数量的Repository类。
一个Repository类只能被一个Service类所依赖。

最初，我们可能会尝试编写一个规则来确保Repository只被Service所依赖，例如：

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

import static com.tngtech.archunit.lang.syntax.ArchRuleDefinition.classes;

public class ArchitectureRules {

    public static final String SUBPACKAGE_NAME_REPOSITORY = "..repository..";
    public 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简洁实现

ArchUnit的DescribedPredicate可以与have条件结合使用，以一种简洁的方式实现自定义检查。我们可以在谓词中直接访问JavaClass对象，并计算其依赖者数量。

import com.tngtech.archunit.core.domain.Dependency;
import com.tngtech.archunit.core.domain.JavaClass;
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;

public class ArchitectureRules {

    public static final String SUBPACKAGE_NAME_REPOSITORY = "..repository..";
    // ... 其他包名常量

    @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(...)))：应用一个自定义条件。describe方法用于创建一个描述性谓词，其第一个参数是违规消息的模板，第二个参数是一个Lambda表达式，用于执行实际的检查。
javaClass.getDirectDependenciesToSelf()：获取所有直接依赖于当前javaClass的依赖关系。这些依赖关系表示哪些类使用了当前的Repository类。
.stream().map(Dependency::getOriginClass)：将依赖关系流转换为依赖者的JavaClass流。
.count() == 1：计算依赖者的数量，并检查是否恰好为1。

优点：

表单大师AI

一款基于自然语言处理技术的智能在线表单创建工具，可以帮助用户快速、高效地生成各类专业表单。

查看详情

代码简洁，易于理解核心逻辑。

缺点：

当规则被违反时，生成的违规消息相对通用，可能不够具体，难以快速定位问题。例如，它只会说“#{dependent classes} != 1”，而不会说明是0个依赖还是多个依赖，以及具体是哪些类依赖了它。

方法二：自定义ArchCondition实现详细违规消息

为了提供更清晰、更具指导性的违规消息，我们可以完全自定义ArchCondition。这在大型项目或需要精确错误报告的场景中尤为有用。

import com.tngtech.archunit.core.domain.Dependency;
import com.tngtech.archunit.core.domain.JavaClass;
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 com.tngtech.archunit.lang.ConditionEvent.createMessage;
import static com.tngtech.archunit.lang.SimpleConditionEvent.violated;
import static com.tngtech.archunit.lang.syntax.ArchRuleDefinition.classes;
import static java.util.stream.Collectors.joining;
import static java.util.stream.Collectors.toSet;

public class ArchitectureRules {

    public static final String SUBPACKAGE_NAME_REPOSITORY = "..repository..";
    public static final String SUBPACKAGE_NAME_SERVICE = "..service..";
    // ... 其他包名常量

    @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) {
                    // 过滤出Service包中的依赖者，确保是Service依赖Repository
                    Set<JavaClass> dependentServiceClasses =
                        javaClass.getDirectDependenciesToSelf().stream()
                            .map(Dependency::getOriginClass)
                            .filter(originClass -> originClass.resideInAnyPackage(SUBPACKAGE_NAME_SERVICE))
                            .collect(toSet());

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

登录后复制

代码解析：

new ArchCondition<JavaClass>("have one dependent class")：创建一个匿名ArchCondition实例，并提供一个描述。
check(JavaClass javaClass, ConditionEvents events)：这是核心方法，ArchUnit会为每个被检查的类调用它。
javaClass.getDirectDependenciesToSelf().stream().map(Dependency::getOriginClass).filter(...)：获取所有直接依赖于当前Repository类的类。这里额外添加了一个filter，确保我们只考虑来自Service包的依赖者，这使得规则更精确地符合“Service依赖Repository”的上下文。
collect(toSet())：将依赖者收集到一个Set中，以避免重复。
if (dependentServiceClasses.size() != 1)：检查依赖者的数量是否不等于1。
生成详细消息：
- 如果dependentServiceClasses.isEmpty()，则表示没有Service依赖这个Repository，生成“has no dependent Service classes”的消息。
- 否则（size > 1），表示有多个Service依赖这个Repository，通过joining操作将所有依赖者的类名连接起来，生成类似“has several dependent Service classes: com.example.service.ServiceA, com.example.service.ServiceB”的详细消息。
events.add(violated(javaClass, createMessage(javaClass, message)))：如果条件被违反，则通过events对象报告违规，并附带详细的违规消息。

优点：

提供极其详细和用户友好的违规消息，能够清晰地指出哪个类违反了规则，以及具体原因（是缺乏依赖还是被多个依赖）。
更高的灵活性，可以根据具体需求定制复杂的检查逻辑和消息格式。

缺点：

代码量相对较大，实现起来比DescribedPredicate更冗长。

注意事项与最佳实践

包名常量化： 示例中使用了SUBPACKAGE_NAME_REPOSITORY和SUBPACKAGE_NAME_SERVICE等常量。在实际项目中，建议将这些包名模式定义为常量，便于管理和修改。
规则描述清晰： 为ArchRule和ArchCondition提供清晰的描述（如"repository_must_have_exactly_one_dependent_class"），这有助于在测试报告中快速理解规则的目的。
细化依赖过滤： 在自定义ArchCondition中，如果你的“依赖者”有特定的类型或包约束（例如，Repository只能被Service依赖），务必在getDirectDependenciesToSelf()之后添加filter()，以确保只考虑符合这些约束的依赖者。
集成到构建流程： 将ArchUnit测试集成到你的CI/CD流程中，确保每次代码提交或构建时都能自动执行架构规则检查，从而在早期发现并修复架构违规。
可读性和维护性： 尽管自定义ArchCondition可能更冗长，但其提供的详细错误信息对于大型团队和长期项目来说，大大提高了规则的可读性和可维护性。

总结

通过ArchUnit的ArchCondition机制，我们能够实现高度定制化的架构规则，远超简单的包依赖检查。无论是采用简洁的DescribedPredicate，还是更详尽的自定义ArchCondition，其核心都在于能够遍历和分析代码结构，并根据业务或架构需求强制执行复杂的约束。在需要精确控制依赖数量的场景下，自定义ArchCondition是确保架构健康和一致性的强大工具。

以上就是ArchUnit规则：确保Repository类仅被单个Service类依赖的详细内容，更多请关注php中文网其它相关文章！