转载

前端架构守护

你是不是经常烦恼于放错层级的代码？你是不是经常在为一坨坨代码而奋斗？你是不是经常这样？

在过去的日子里，如我在那篇『如何提升 Web 应用的代码质量』所提及，我们采用了一系列的措施如 pre-push, pre-commit 在基础层级对架构进行守护。但是，这样仍然是远远不够的。

因为在『架构金字塔』里，这些基础的规范、原则等只是沧海一粟，往往无助于对软件架构的辅助设计作用。所以，我们需要架构守护这样的工具。

从 ArchUnit 说起

架构守护是在过去的两三年里，新起的一个话题。因为人们需要在：

系统演进后架构守护，减缓系统再次腐化
应用架构适应度函数（Architectural fitness function）来驱动架构演进

于是乎，在 Java 世界里，越来越多的项目采用了 ArchUnit 这样的工具来防止架构的腐烂。

ArchUnit 是一个基于 Java 的测试库，用于检查代码的结构特性，如包和类的依赖关系、注解验证，甚至还能检查代码分层是否一致。

你可以通过如下的测试，来确保某些类型的文件放置于指定的包名 & 文件名下：

@ArchTest
    static final ArchRule layer_dependencies_are_respected_with_exception = layeredArchitecture()

            .layer("Controllers").definedBy("com.tngtech.archunit.example.layers.controller..")
            .layer("Services").definedBy("com.tngtech.archunit.example.layers.service..")
            .layer("Persistence").definedBy("com.tngtech.archunit.example.layers.persistence..")

            .whereLayer("Controllers").mayNotBeAccessedByAnyLayer()
            .whereLayer("Services").mayOnlyBeAccessedByLayers("Controllers")
            .whereLayer("Persistence").mayOnlyBeAccessedByLayers("Services")

            .ignoreDependency(SomeMediator.class, ServiceViolatingLayerRules.class);

并通过诸如于 mayNotBeAccessedByAnyLayer 或者 mayOnlyBeAccessedByLayers 来限制它们的层级调用。一旦出现了不合理的调用，如 Controller 层，直接调用了 Persistence 层，那么测试就会失败。

PS：上述的代码只是其众多功能中的一部分。

自了解了相关的概念之后，我开始思考如何在前端去做这样的事情。

架构守护

所谓的架构守护，是 以测试的方式，来防止架构模式的抽象被破坏 。

当我在项目上实施了整洁架构，我便大致知道如何去实现这样的工具。因为所谓的架构守护，实际上便是 以测试的方式，来防止架构模式的抽象被破坏 。即，我们在设计架构的时候，会制定出一些通用的规则，诸如于函数的命名方式、文件的命名规则等等；与此同时，我们还会通过分层架构来限制调用，而分层架构是否合理的体现，便可以通过依赖的方式来分析，等等。

从我的角度来看，理想的架构守护应该要有这样的特征：