架构规则：代码检查器无法验证的那些

本文探讨了那些无法通过代码检查器（linter）自动验证的软件架构规则。作者指出，虽然代码检查器能捕获代码风格、潜在错误和简单设计违规，但真正影响系统可维护性和可扩展性的高层架构决策——如模块依赖方向、边界隔离和层次结构——往往需要人工审查和团队共识来保障。文章强调了超越自动化工具的架构治理重要性。

背景速读

- 作者讨论的是软件架构中一类特殊的规则：它们不是具体的代码风格或已知安全漏洞（这些可以被 linter 自动检查），而是关乎模块之间的依赖方向、分层边界和领域隔离等**宏观结构问题**。 - 传统 linter（如 ESLint、Pylint）擅长检查单一文件内的语法或模式，但理解不了“这个模块是否不该调用那个模块”这类**跨文件、跨包**的关系。这类规则往往要靠人工 Code Review 来维护。 - 随着项目变大，架构会自然“腐化”（architecture erosion）：开发者图方便绕过了设计约束，导致系统变得难以修改和测试。 - 文中提到的对策，包括依赖注入、端口与适配器（即六边形架构）、模块化封装等，都是业界常见的**防御性设计实践**——但问题在于，这些规则很难用自动工具强制执行。