GeoXMind

分层架构怎样限制依赖

说明分层如何分离职责和限制依赖，并分析跨层调用、共享模型与严格分层的实际取舍。

分层架构怎样限制依赖

分层架构把系统职责按抽象程度或技术角色组织，并规定层之间允许怎样依赖。它的价值不在于形成几个名称整齐的目录，而在于让高层规则不必理解所有底层细节，使变化、测试和替换能够落在可控制范围。层的数量和名称没有通用答案，依赖规则才是核心。

层表示逻辑责任而不是机器数量

常见划分会区分界面、应用协调、领域规则和基础设施，但这些只是可能的逻辑责任。同一进程内可以包含多个层，一个层也可能跨多个包。把前端、后端和数据库称为“三层部署”，与源码中的逻辑分层不是同一件事。

部署层关注进程、网络和节点，逻辑层关注代码职责和依赖。两者可能相关，却不能相互替代。应用服务与数据库分开部署，并不证明业务规则已经与存储细节分离；所有规则仍可能直接写在 SQL 或控制器中。

层边界需要回答：本层对外提供什么能力，允许依赖哪些层，哪些数据结构可以穿越边界，失败如何表达。只有目录名称而没有规则，调用会逐渐绕过边界，最终每层都知道其他层的内部实现。

依赖方向保护高层决策

高层业务规则通常比数据库驱动、Web 框架和第三方 SDK 更能表达系统长期价值。如果高层代码直接依赖具体框架类型，替换存储或测试规则就需要携带整套基础设施。通过稳定接口隔离易变细节，可以让实现依赖业务所需的契约。

这类依赖反转并不要求为每个类创建接口。边界应放在变化原因不同、替换成本高或测试隔离有明确价值的位置。为不会替换的简单值对象增加多层包装，只会增加导航成本。

依赖方向也包括数据模型。若数据库实体直接穿过所有层进入公共 API，表字段变化会扩散到调用者；若每层都复制一套几乎相同对象，映射成本又可能超过收益。模型转换应保护确实不同的语义和生命周期，而不是机械追求“纯净”。

严格分层与开放分层有不同代价

严格分层要求一层只能调用相邻的下一层，使每次交互都经过统一边界。这有利于集中约束，却可能产生大量只转发参数的代码。开放分层允许跨过中间层调用更底层能力，路径更短，但中间层的规则可能被绕开。

是否允许跨层，应按语义判断。只读查询若不需要领域状态转换，可以使用专门查询路径；发布、支付或权限变更等关键动作则应经过负责不变量的层。例外需要显式记录，否则开放路径会逐渐成为默认路径。

性能也不是随意绕层的充分理由。大多数函数调用成本远小于数据库与网络开销。真正瓶颈应通过测量确认，再决定批量接口、专用读取模型或缓存，而不是提前破坏依赖规则。

横切能力不能变成隐蔽耦合

认证、日志、事务、缓存和指标会跨越多个层。若每层分别实现，行为容易不一致；若全部藏在框架拦截器中，关键语义又可能无法从代码看出。横切能力需要明确在哪个边界生效，以及业务代码能否感知失败和上下文。

事务边界尤其影响分层。一个应用动作可能协调多个领域对象和仓储，事务通常应围绕该动作，而不是由每个数据访问函数独立提交。远程服务不能简单纳入本地数据库事务，跨服务一致性需要另外设计重试、补偿或状态机。

安全检查也有不同层次。入口层可以验证令牌和格式，资源级授权仍需靠近拥有对象语义的服务端规则。只在界面隐藏按钮，或只在最底层按表过滤，都可能遗漏真实操作意图。

分层失败常表现为职责错位

“贫血中间层”只把请求转发给数据库，说明层没有承担独立责任；“万能服务层”容纳所有业务，则说明模块边界不足。控制器中出现复杂状态转换、仓储中混入用户提示文本、领域规则依赖 HTTP 状态码，都是职责泄漏信号。

另一个常见问题是循环依赖：领域层引用基础设施实现，基础设施又调用领域服务。循环会使单独测试和构建困难，也让初始化顺序和异常处理变得隐蔽。应重新判断规则所有权，提取稳定契约，而不是用全局容器掩盖循环。

共享工具模块也可能破坏层次。若所有层都向其中放入业务常量和数据库辅助函数，它会变成无边界的共同依赖。共享内容应小而稳定，业务概念仍应由明确模块拥有。

用变化和测试检验层次是否有效

分层是否合理，可以用具体场景检查：更换存储实现需要改哪些层，新增发布规则是否触碰控制器和数据库细节，领域规则能否在不启动 Web 容器的情况下测试，接口变更是否影响内部实体。答案比层数更能说明结构质量。

运行时架构也要验证与设计一致。静态依赖检查可以禁止特定包方向，集成测试可以确认事务和序列化边界，架构文档则说明允许的例外。SEI 强调架构要支持质量属性分析和持续演进；分层只是实现这些目标的一种结构手段，不是系统成熟度的标签。

当一个变化需要跨越所有层时，不一定是分层失败，因为有些需求本来就是端到端的。真正要避免的是每个变化都无差别扩散，以及任何层都能绕过拥有规则的边界。有效分层让依赖方向和责任可以被解释、检查和调整。

资料依据