分层架构设计：从概念到实践，彻底理解依赖管理与层间边界

分层架构这个词，我在带新人的时候几乎每个月都要讲一遍。有意思的是，很多人第一次听到“分层”两个字，第一反应是“不就是把代码分几个文件夹吗”，然后过两个月被自己写的循环依赖折磨得死去活来，再回来找我聊，才真正理解分层到底在解决什么问题。这篇内容我想把分层架构设计概念从头到尾拆一遍，不讲教科书上那种干巴巴的定义，而是讲清楚每一层为什么存在、边界怎么划、依赖方向为什么不能反、以及我在实际项目里踩过的那些坑。不管你是刚接触系统设计的新手，还是已经写过几年代码但总觉得架构“差点意思”的开发者，应该都能从里面找到能直接用的东西。

1. 分层架构到底在解决什么问题

1.1 从一次典型的“代码烂掉”过程说起

我见过太多项目是这么烂掉的：最开始只有一个业务类，里面既有数据库查询，又有业务计算，还顺手把返回结果拼成了前端要的格式。第一周跑得很好，第二周加了个新需求，在原来的方法里加了个 if；第三周要换数据库，发现业务逻辑和 SQL 缠在一起，动一处牵全身。这时候有人提议“我们分层吧”，于是把代码拆成三个文件，但拆完之后发现，业务层里还是在直接 new 数据库连接，控制层里还是在做业务判断——形式上分了层，实质上还是坨在一起。

这个过程的本质问题是：变化的方向没有被隔离。数据库会换、界面会改、业务规则会调整，这三类变化的频率和原因完全不同。分层架构的核心价值，就是把这些不同原因引起的变化隔离开，让改数据库的时候不用碰业务代码，改界面的时候不用碰数据访问代码。用一句话概括：分层不是为了好看，是为了让每一类变化只影响一个地方。

1.2 分层的本质是“依赖方向的管理”

很多人把分层理解成“横向切块”，其实更准确的理解是“纵向管理依赖”。经典的三层架构里，表现层依赖业务层，业务层依赖数据访问层，依赖方向是单向向下的。这个单向性才是分层的灵魂。一旦出现数据访问层反过来调用业务层，或者业务层直接依赖表现层的某个类，分层就名存实亡了。

我用一个生活化的类比来解释：分层就像一家餐厅。前厅服务员（表现层）负责接待客人、记录点单，后厨（业务层）负责按订单做菜，仓库（数据访问层）负责提供食材。服务员不会自己跑进仓库拿食材，后厨也不会跑到前厅去招呼客人。每一层只跟相邻的下一层打交道，这就是依赖方向的约束。如果哪天服务员直接冲进仓库翻东西，整个餐厅的秩序就乱了——对应到代码里，就是耦合。

1.3 分层带来的三个实际收益

第一个收益是可替换性。数据访问层封装好之后，从关系型数据库换到别的存储方案，理论上只需要重写数据访问层的实现，业务层代码一行不动。我做过一个项目，早期用本地文件存储，后来换成关系型数据库，因为数据访问层接口定义得干净，替换工作只花了两天。

第二个收益是可测试性。业务层的逻辑不依赖真实的数据库和界面，测试的时候可以用模拟实现替换掉数据访问层，单元测试跑得飞快。这一点在实际项目里价值极大，尤其是业务规则复杂、分支多的场景。

第三个收益是团队协作的边界清晰。不同的人可以负责不同的层，接口约定好之后并行开发，互不干扰。新人上手也快，因为每一层的职责是明确的，不用一上来就理解整个系统。

注意：分层不是越多越好。我见过有人把一个简单的增删改查项目分成六层，每层就几行转发代码，维护成本反而更高。层的数量应该由系统的复杂度和变化点决定，简单系统三层足够，复杂系统再考虑更细的划分。

2. 经典分层模型的拆解与选型考量

2.1 三层架构：最常用也最容易被误解

三层架构指的是表现层、业务逻辑层、数据访问层。这个模型流传最广，但也最容易被机械套用。我先把三层的职责说清楚：

这张表看起来简单，但实际项目里最常见的错误就是职责越界。比如参数校验，很多人放在业务层，理由是“业务层更安全”。我的做法是：格式校验（比如字段非空、长度限制）放在表现层，业务规则校验（比如余额是否充足、状态是否允许流转）放在业务层。这个划分的依据是——格式校验跟界面形态相关，业务校验跟业务规则相关，各自归各自管。

2.2 四层架构：领域层独立出来的意义

当业务逻辑复杂到一定程度，三层架构里的业务层会变得臃肿，既有业务流程编排，又有核心领域规则。这时候把领域逻辑单独抽出来成为领域层，形成表现层、应用层、领域层、基础设施层的四层结构，是更合理的选择。

应用层负责流程编排和事务控制，领域层负责核心业务规则，基础设施层负责技术实现（数据库、消息、缓存等）。这个划分的关键在于：领域层不依赖任何技术细节，它只表达业务概念。这样领域逻辑可以独立测试、独立演进，技术选型的变化不会污染业务核心。

我个人的经验判断标准是：如果业务层里超过一半的代码是在做流程调度而不是规则计算，说明流程和规则混在一起了，可以考虑拆分。但要注意，四层架构对团队的设计能力要求更高，如果团队对领域建模不熟悉，强行拆反而会拆出一堆贫血对象，得不偿失。

2.3 分层与分模块的区别

这里要澄清一个高频混淆点：分层是纵向的，分模块是横向的。分层按技术职责切，分模块按业务能力切。一个电商系统，纵向分表现层、业务层、数据层，横向分订单模块、库存模块、支付模块。两者是正交的，可以同时存在。

实际项目里我通常的做法是：先按业务模块划分大边界，每个模块内部再分层。这样既保证了业务边界的清晰，又保证了技术职责的隔离。如果只分层不分模块，所有业务逻辑挤在一个业务层里，照样会乱；如果只分模块不分层，每个模块内部技术细节和业务逻辑混在一起，同样难维护。

2.4 为什么依赖方向不能反转

依赖方向必须单向向下，这个规则背后的逻辑是：越往下层，越稳定、越通用；越往上，越易变、越具体。数据访问层封装的是存储细节，相对稳定；表现层跟着界面需求变，变化频繁。如果让稳定的层依赖易变的层，稳定的层就会被拖着一起变，隔离的意义就没了。

依赖倒置是这条规则的一个补充手段。业务层需要调用数据访问能力，但不想直接依赖具体实现，于是定义一个接口放在业务层，数据访问层去实现这个接口。这样依赖方向在源码层面是“数据访问层依赖业务层的接口”，但运行时调用方向还是业务层调数据访问层。这个技巧在需要替换实现或者做单元测试时非常有用，本质上是把“依赖具体”变成了“依赖抽象”。

3. 分层落地的核心实操要点

3.1 层间接口怎么设计才算合格

接口设计的第一个原则是面向业务语义，不暴露技术细节。数据访问层的接口应该叫“按用户标识查询账户”，而不是“执行 select 语句”。接口参数和返回值应该是业务对象，而不是数据库行对象或者结果集。这样做的好处是，上层完全感知不到底层用的是关系库还是别的存储。

第二个原则是接口粒度适中。太细的接口会导致上层调用次数过多，太粗的接口会导致下层实现臃肿。我的经验是：一个接口方法对应一个完整的业务查询或操作意图，而不是对应一张表的某个字段操作。比如“查询用户及其关联的订单列表”可以是一个接口方法，但“查询用户名字”和“查询用户年龄”拆成两个方法就过细了。

第三个原则是异常处理要统一。下层抛出的技术异常（比如连接超时）不应该原样透传到上层，应该在层边界转换成业务语义的异常。这样表现层不需要知道底层用的是什么技术，只需要处理业务层面的错误情况。

3.2 数据传输对象的使用边界

跨层传递数据时，我强烈建议使用专门的数据传输对象，而不是直接把数据库实体或者领域对象传来传去。原因有三：第一，数据库实体会随着表结构变化，直接传上去会导致上层跟着改；第二，领域对象可能包含业务方法，传到表现层容易被误用；第三，不同层需要的数据字段往往不同，用一个对象硬传会造成字段冗余和安全隐患。

实际做法是：数据访问层返回数据库实体，业务层把它转换成领域对象做计算，需要往表现层传的时候再转换成传输对象。转换代码看起来是“重复劳动”，但它是层与层之间的缓冲带，隔离了各层数据模型的变化。我踩过的坑是早期图省事直接传实体，后来加了个敏感字段，结果不小心透到了接口返回里，排查了半天。

3.3 事务边界应该放在哪一层

事务边界放在业务层，这是基本原则。表现层不应该管事务，因为它不知道一个业务操作涉及几次数据写入；数据访问层也不应该管事务，因为它只负责单次数据操作，不知道业务上的原子性要求。

具体实现上，事务的开启和提交应该包裹在业务层的一个完整业务方法上。比如“转账”这个业务操作，涉及扣款和入账两次数据写入，事务边界就应该在业务层的转账方法上。这里要注意的是，事务范围不要过大，一个事务里不要包含远程调用或者耗时操作，否则会长时间占用连接资源。

3.4 分层目录结构的组织方式

目录结构是分层落地的物理体现，我推荐按层建顶层目录，层内再按业务模块组织。比如：

src/ presentation/ order/ user/ application/ order/ user/ domain/ order/ user/ infrastructure/ persistence/ messaging/

这种结构的好处是层的边界一目了然，新人进来先看顶层目录就知道系统分了几层。层内按模块组织，保证了同一业务的相关代码聚在一起。我不推荐按模块建顶层目录再在模块内分层，因为那样层的全局约束不容易被看到，容易出现某个模块偷偷跨层调用的情况。

提示：目录结构定下来之后，最好用构建工具或者静态检查工具加一条规则，禁止下层引用上层的包。靠人自觉是靠不住的，工具约束才是长久之计。

4. 分层实践中的常见问题与排查实录

4.1 循环依赖是怎么产生的，怎么破

循环依赖是分层实践里最常见的问题，典型表现是业务层引用了表现层的某个工具类，同时表现层又引用业务层。产生的原因通常是“图方便”——某个格式化方法在表现层写好了，业务层也想用，就直接引用了。

破解思路分三步：第一步，找出循环依赖的具体类，用依赖分析工具扫一遍就能定位；第二步，判断这个被双方共用的东西到底属于哪一层，如果它是纯技术工具（比如日期格式化），应该下沉到公共基础设施里；第三步，如果是业务概念被错误放置，把它移到正确的层，然后调整引用。

预防手段比补救更重要。我在项目里会约定一条硬规则：任何跨层引用必须经过接口，不允许直接引用实现类。这条规则配合静态检查，能挡掉大部分循环依赖。

4.2 业务层越来越臃肿怎么办

业务层臃肿的典型症状是一个类几千行，方法几十个，改一个需求要在里面找半天。根本原因是把流程编排、规则计算、数据转换全塞在了一起。

我的处理办法是先做职责识别：把方法按“流程调度”“规则判断”“数据组装”分类，流程调度类的抽到应用层，规则判断类的聚合成领域对象，数据组装类的移到转换器里。这个过程不需要一次性重构完，可以按需求迭代逐步迁移。关键是先建立分类意识，新写的代码不要再往老类里堆。

另一个实用技巧是给业务层设一个“行数警戒线”，比如单个类超过五百行就强制 review，看看是不是职责过载。这个数字不是绝对的，但它能起到提醒作用。

4.3 层间数据不一致的排查思路

跨层传递数据时，偶尔会遇到“上层拿到的数据和下层查出来的不一致”这种诡异问题。排查顺序我一般是这样的：

我遇到最多的是第三步——上层为了展示方便，直接在传输对象上改了字段，而这个对象又被别处引用，导致数据被污染。解决办法是传输对象尽量设计成不可变对象，或者在上层使用前做一次防御性拷贝。

4.4 分层过度导致开发效率下降

这是另一个极端。有些团队把分层当成教条，每个层都要求严格的接口、转换、异常包装，结果一个简单的查询需求要写五六个类。我的判断标准是：如果一层里超过七成的方法是纯转发，这层就是多余的。

分层的目的是隔离变化，如果一个层没有隔离任何实际变化，它只是增加了调用链长度。实际项目里我会根据变化频率动态调整：变化频繁的边界保留分层，几乎不变的部分允许合并。架构是服务于业务的，不是反过来。

4.5 单元测试怎么配合分层写

分层做得好，测试就好写，这是分层的一个隐性红利。我的测试策略是按层分配：

• 数据访问层：用真实数据库的轻量实例做集成测试，验证查询和映射正确。
• 业务层：用模拟实现替换数据访问层，专注测业务规则和分支覆盖。
• 表现层：测参数校验和输出格式，业务逻辑用模拟的业务层替代。

这样每一层的测试都聚焦在自己的职责上，跑得快、定位准。如果发现某一层特别难测，往往说明这层的职责没划清楚，或者依赖没管好，这时候应该回头调整设计，而不是硬写测试。

5. 分层架构的演进与取舍经验

5.1 什么时候该引入分层，什么时候不该

不是所有项目一上来就需要严格分层。我的经验是：原型阶段和一次性脚本不分层，正式产品且预期会持续迭代的才分层。分层的成本在于额外的类和转换代码，收益在于长期的可维护性。如果项目生命周期短、变化少，分层的收益覆盖不了成本。

判断信号可以看两条：一是需求变更的频率，如果每周都有新需求进来，分层值得做；二是团队规模，超过三个人协作，分层带来的边界清晰度就很有价值。反过来，一个人维护的小工具，硬套四层架构纯属自找麻烦。

5.2 分层架构和微服务的关系

经常有人问，都上微服务了还需要分层吗？答案是更需要。微服务解决的是进程间的业务边界问题，分层解决的是进程内的职责隔离问题，两者不冲突。一个微服务内部如果代码不分层，照样会烂，只是烂的范围被限制在一个服务里而已。

实际做法是：微服务划分确定业务边界，每个服务内部再按分层组织代码。服务之间的调用通过接口契约，服务内部的调用通过层间接口。这样宏观和微观两个层面都有清晰的边界。

5.3 我踩过的三个真实坑

第一个坑是过早抽象。项目初期就设计了复杂的层间接口和转换体系，结果业务方向调整，一半的层根本用不上，删起来还牵连一片。教训是：分层从最简的三层开始，等变化点真正出现再细化。

第二个坑是层间共享工具类。为了方便，建了个公共工具包，结果各层都往里塞东西，最后这个包变成了大杂烩，依赖关系彻底乱掉。后来改成公共包只放纯技术工具（字符串处理、日期计算），业务相关的工具一律归到对应层。

第三个坑是忽视构建约束。早期靠代码评审来保证不跨层调用，评审一忙就漏，等发现时已经积了一堆违规引用。后来在构建流程里加了依赖检查，违规直接构建失败，问题才根治。

5.4 给不同阶段团队的建议

刚起步的小团队，我建议先把三层架构的职责边界讲清楚，用目录结构把层体现出来，接口先简单定义，重点是养成“不跨层直接调用”的习惯。这个阶段不要追求完美的抽象，能跑通、边界清楚就行。

有一定规模、业务开始复杂的团队，可以考虑把领域逻辑独立出来，引入应用层做流程编排。这个阶段的关键是培养领域建模的意识，让业务规则有独立的表达位置，而不是散落在各个服务方法里。

成熟团队可以进一步在层内做模块化，配合依赖检查和自动化测试，把分层约束固化到工程流程里。这个阶段分层已经不是靠人记规则，而是靠工具保障。

最后分享一个我在实际项目里一直用的自检方法：随便挑一个需求变更，问自己“这个改动会波及几层”。如果答案是超过两层，说明层间耦合还是太重，值得回头看看接口设计和职责划分。分层做得好不好，不看图画得多漂亮，看的是改一个需求时，你能不能快速说出“只需要动这一层”。这个判断标准，比任何架构评审都实在。