本文深入探讨了如何利用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。
优点：
Revid AI
AI短视频生成平台
96 查看详情 
代码简洁，易于理解核心逻辑。
缺点：
当规则被违反时，生成的违规消息相对通用，可能不够具体，难以快速定位问题。例如，它只会说“#{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("have one dependent class") { @Override public void check(JavaClass javaClass, ConditionEvents events) { // 过滤出Service包中的依赖者，确保是Service依赖Repository Set 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(“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类依赖的详细内容，更多请关注创想鸟其它相关文章！
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。
如发现本站有涉嫌抄袭侵权/违法违规的内容， 请发送邮件至 chuangxiangniao@163.com 举报，一经查实，本站将立刻删除。
发布者：程序猿，转转请注明出处：https://www.chuangxiangniao.com/p/1038376.html
微信扫一扫 
支付宝扫一扫 
