云海天狼软件架构这行，聊得最多又经常说不清的一个话题，就是“应用分层”。不少团队从单体写起，一个Service包打天下，Controller里塞满业务逻辑，等到改需求、查Bug、做扩展的时候，才发现代码已经变成一团乱麻。我自己在几个项目里都踩过这种坑，后来重新梳理分层之后，整个团队在迭代节奏和问题定位速度上都有了质的提升。
这篇文章把我对应用分层的完整思考和实践经验整理出来，从分层要解决的本质问题，到具体的分层方案、职责边界，再到落地时的一些实用建议和常见问题，全程干货，不整虚的。适合正在为代码结构头疼的后端开发者、即将接手大型项目的新人，以及想给团队代码定规范的技术负责人。
1. 为什么要分层：先理解分层的核心价值
1.1 分层的本质是管理依赖，不是画组织结构团
很多团队讨论分层的时候，容易把“怎么划Package”和“怎么分模块”搞混。其实分层解决的核心问题只有一个：依赖关系的方向。代码复杂到一定程度，最大的敌人不是重复代码，而是“谁都依赖谁”形成的网状结构。改一个底层方法，顺着调用链往上，可能有一百个调用方要跟着检查。
分层的作用，是通过一种约定，把“谁可以依赖谁”这件事规定死。上层允许调用下层，下层绝不反向依赖上层。这样整个系统从无序的网，变成有方向的、像金字塔一样的稳定结构。
我记得最早自己写商城系统，订单、库存、支付三个模块互相调用。订单服务调库存，库存又调订单查状态，支付回调还要改这改那。看似“方便”，实际上每次上线都要全量回归，改任何一处都可能牵出连环问题。后来把依赖关系按照业务归属和技术职责理清楚，其实大部分问题根本不是“业务复杂”，而是“结构混乱”。
1.2 分层能带来哪些实际好处
先说可维护性。没有分层约束的项目，代码大概率是“只敢看、不敢动”。因为每次改动的影响范围不透明，只能靠人肉记忆去猜。分层之后，每层有自己的职责轨道，改动一个接口的实现，只要保证对外契约不变，调用方基本是无感知的。
再说可测试性。分层设计的特点是“依赖点都是边界”，边界天然适合用Mock隔离。比如Service层测试，可以Mock掉Repository层的实现；Controller层测试，可以Mock掉Service层。没有分层的代码，测试一个方法会连带初始化数据库连接、依赖容器、缓存等等，测试成本高得吓人，最后团队会自动用“不写测试”来逃避。
最后是团队协作。分了层，每个开发同学在申请任务的时候，脑子里天然的有一个“这个改动主要落在哪一层”的判断。多个同学同时开发，代码归属变清晰，Merge冲突的概率也大幅下降。这一点在团队从5人涨到20人的时候，体感非常明显。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 常见分层方案与适用场景对比
2.1 经典三层架构：最简单实用的默认选择
经典三层架构，接口层（API/Controller）、业务层（Service）、数据访问层（DAO/Repository）。这是绝大多数中小型项目的默认选择，也是很多Web开发框架文档里推荐的默认结构。
code复制controller → service → repository → DB
这套方案的好处就是足够简单，大脑理解成本极低。新人入职看半天代码就能上手，写起来也不用想太多“我这个类应该放哪”这种问题。尤其是团队以业务需求驱动、不搞架构自嗨的项目，经典三层往往最稳。
但它的问题是，当业务逻辑复杂到一定程度，Service层会膨胀成“上帝类”。一个OrderService可能几百上千行，订单的创建、取消、退款、发货逻辑全塞在一起，到了后期还是乱。
2.2 DDD风格分层：复杂业务场景的解法
领域驱动设计风格的分层，一般大致分为接口层、应用层、领域层和基础设施层。这跟经典三层最大的区别，是把业务规则从Service里拆出来，下沉到领域层。应用层只负责流程编排，领域层负责业务规则和状态变化。
code复制controller → application service → domain → infrastructure
这个方案的优点是在业务足够复杂、多状态流转、业务规则需要复用的时候，代码的“表达力”会非常强。订单状态的流转策略写在领域对象内部，而不是散落在Service的if else里。
但它的门槛也高。领域建模能力需要经验积累，如果团队对业务边界没有清晰的共识，硬上DDD的结果就是“伪DDD”：领域层变成贫血的POJO，应用层变成新的上帝类，开销增加、收益为零。
2.3 两种方案对比：什么时候选哪个
| 对比维度 | 经典三层 | DDD风格分层 |
|---|---|---|
| 业务复杂度 | 中低复杂度够用 | 高复杂度表现更好 |
| 团队门槛 | 低，新人容易上手 | 高，需要建模经验 |
| 代码表达力 | 一般，规则在Service里 | 强，规则在领域层 |
| 维护成本 | 项目小的时候很低 | 前期较高，后期曲线平滑 |
| 适用范围 | 常规CRUD、管理端、简单业务 | 交易系统、规则引擎、复杂状态机 |
从我自己的实践看，如果项目的核心逻辑还停留在“数据增删改查”阶段，就别折腾DDD分层的概念了。相反，如果业务本身复杂度是核心难点，才值得考虑领域层的设计。不要为了架构而架构，架构是为降低复杂度服务的，不是为简历上的亮点服务的。
3. 一次完整的应用分层重构实操
3.1 现状盘点：找出代码结构里的“坏味道”
动手重构前，第一步不是画新架构图，而是搞清楚现在代码为什么难搞。我通常会先做一版“结构体检”，把这些问题标注在代码里：
- 某个Service类代码行数是否超过800行。
- Controller层是否直接操作了数据模型或SQL相关对象。
- Repository层是否包含业务判断逻辑。
- 是否出现循环依赖（A调B，B调A）。
- 是否大量存在“一个方法做五件事”的长方法。
体检的产出不是精美的报告，是一份“问题清单+影响范围说明”。这份清单要能看到具体类名、具体方法、以及如果不重构未来会踩什么坑。有了依据，重构才有说服力。
3.2 定义目标分层结构：包结构与依赖规则
以经典三层为底座，再做一些扩展。我的常用做法是按技术职责 + 模块归属双重维度组织包结构：
code复制com.company.project
├── controller
│ └── order
│ └── OrderController.java
├── service
│ └── order
│ ├── OrderService.java
│ └── impl
│ └── OrderServiceImpl.java
├── repository
│ └── order
│ ├── OrderRepository.java
│ └── impl
│ └── OrderRepositoryImpl.java
├── domain
│ └── order
│ ├── Order.java
│ └── OrderStatus.java
└── common
└── result
└── ResultWrapper.java
层与层之间的依赖规则，要写成一条硬性约定：
依赖方向只允许自上而下：controller → service → repository。domain（实体）和common（通用工具）可以被任意层引用，但绝不能反过来依赖上层。严禁在Controller里直接调用Repository，严禁在Repository里写业务流程。
依赖规则最好嵌入到工程规范里，能通过自动化检查就自动检查。现在很多语言的静态扫描工具都能配置依赖规则规则，或者用ArchUnit这类专门的依赖规则测试库，在CI里加一个小用例，有违规就直接fail build。
3.3 典型重构步骤：以订单模块为例
真正动手重构时，我习惯分五个步骤渐进执行，每步都保证代码可编译、测试可通过：
第一步，先把实体类（PO/DO）和传输模型（DTO/VO）分离。这一步比较简单，但收益很大。让Controller只依赖VO，Repository只依赖DO，Service在中间做转换。虽然多了“搬运代码”，但从根上避免了“数据库表结构变化直接传到页面”的耦合问题。
第二步，把Controller变薄。把Controller里出现的所有业务判断、数据操作代码，迁移到Service层。Controller只负责参数解析、调用Service、包装返回结果。这个是纯搬运工作，也是最容易肉眼验证的对等重构。
第三步，抽取Repository接口。把数据访问操作从Service里彻底剥离开。所有数据查询方法都回归到Repository接口中，Service只依赖接口，不关心实现是MyBatis还是JPA还是内存Map。这为将来换存储或写单测铺好了路。
第四步，处理Service层的“上帝代码”。如果一个Service方法超过50行，或者类方法超过10个，就要想想能不能拆分。一个常用技巧是拆分“职责单一的helper”，把通用规则抽出来；另一种是按业务角色拆分，比如订单创建逻辑拆成OrderCreateService，状态流转拆成OrderStatusService。
第五步，统一调用入口和返回结构。Service返回业务数据，Controller包装统一结构（比如ResultWrapper）。过程中要同步维护异常处理逻辑，所有业务异常在顶层统一接收和转换，避免出现“每层都try-catch包一层”的嵌套地狱。
3.4 重构验证：怎么知道没有改坏东西
重构最怕的不是工作量大，是“重构完行为变了”。我的验证方案有两个层面：
第一层是现有自动化测试。重构之前，先把核心业务接口的集成测试跑一遍，把结果记录下来作为基准。重构过程中每一步完成后都跑一遍全量测试，保证行为不变。没有测试覆盖的旧代码，先补“特征测试”，锁定当前行为，再开展重构。
第二层是Code Review的“差异最小化”检查。审查重构PR的时候，重点不是看新代码好看不好看，而是逐个确认“这个改动是不是真的只挪了位置”。如果某个文件同时出现了“移动旧代码”和“新增新功能”，这条PR要拆掉。这能最大化避免重构和需求变更混在一起导致的问题难以定位。
4. 工具选型和工程保障：让分层设计落地不被打破
4.1 依赖检查自动化：ArchUnit与依赖规则扫描
单靠“团队自律”来维护分层，基本等于没有维护。人的记忆不可靠，尤其在团队扩张、项目时间紧张、新人加入的时候，架构约束几乎是第一批被丢掉的束身衣。我的做法是在CI里跑专门的分层依赖测试。
以Java为例，ArchUnit可以非常方便地把分层依赖规则写成测试用例：
java复制@AnalyzeClasses(packages = "com.company.project")
public class LayeredArchitectureTest {
@Test
void controllerShouldOnlyDependOnServiceLayer() {
JavaClasses classes = new ClassFileImporter()
.importPackages("com.company.project..");
ArchRule rule = layeredArchitecture()
.consideringAllDependencies()
.layer("Controller").definedBy("..controller..")
.layer("Service").definedBy("..service..")
.layer("Repository").definedBy("..repository..")
.whereLayer("Controller").mayNotBeAccessedByAnyLayer()
.whereLayer("Service").mayOnlyBeAccessedByLayers("Controller")
.whereLayer("Repository").mayOnlyBeAccessedByLayers("Service");
rule.check(classes);
}
}
这样写一次，以后每个MR如果出现依赖方向违规，流水线直接红牌。省去“架构师口头提醒一百遍”的沟通成本。
4.2 组件化与接口边界：让依赖方向在编码层面可感知
在编码层面的另一个保障手段，是把跨层依赖收窄为接口。每个Service只暴露自己真正需要的方法，Repository接口不要定义一大堆“可能会有用”的方法。
一个我印象很深的教训是，某个项目里的UserRepository接口里二三十个查询方法，实际使用不到三分之一。方法多了之后，团队里新同学图省事，会“顺手”在业务代码里拼接多个Repository方法做业务处理，导致业务规则散落在Service外面。后来收紧接口边界，把“查询用户基本信息”和“查询用户扩展属性”拆到不同接口，反而让业务代码更清晰了。
4.3 抽象但别过度：随手窝藏的“通用工具层”陷阱
很多团队在落地分层时，不自觉造出第四个“万能层”，就是common/utils层。工具类、常量类、通用枚举、全局异常包装，什么都往里丢。时间久了，这个包变成新的垃圾堆。
我的经验是：工具类不要做“面向实现”的分类，而是做“面向业务”的分类。通用性强的（如日期格式化、加密解密、集合操作）放在基础工具包没问题；但跟业务强相关的（如订单号生成器、价格计算器、库存校验器）一定要放在对应的业务模块内，千万不要为了“复用”去搞一个OrderUtils、PayUtils满天飞的“业务垃圾场”。
5. 实操中的几个关键问题与排查实录
5.1 Controller层到底能不能写业务逻辑
这个问题业界争论很多，我的个人判断是控制器可以做“简单的协议适配”，但绝不做“业务决策”。参数校验、数据格式转换、调用服务、包装响应，这些算协议适配；判断订单是否可以退款、根据用户类型计算折扣、决定调用哪个下游服务等，这些必须下沉到Service层。
一个自查标准很实用：如果Controller里的逻辑，在别的地方（比如消息队列消费者、定时任务）也需要做一遍，那这块逻辑就不该待在Controller里。用场景倒逼归属，比空谈“职责”更能让团队达成一致。
5.2 Service层互相调用：同层依赖怎么解
经典三层架构里，Service层之间互相调用经常发生。一个OrderService要调用UserService查用户信息，这时直接用Spring注入UserService接口就行，比把UserRepository塞给OrderService更符合依赖方向。Service层之间的调用允许存在，但要注意“不要让跨Service调用产生无底洞”：A→B→C→A这种循环依赖在Spring容器启动阶段就能发现并报错，一旦出现，大部分情况说明服务边界划分不对，需要重新审视。
我个人的建议是同一层允许调用，但只允许调用接口、不允许调用实现，并且跨Service调用的方法语义要单一，尽量避免为一个看起来“很省事”的查询方法重复调用同一个Service十几次。
5.3 Repository层的事务边界与功过分明
事务和DataSource操作安排在哪一层？我的做法是：事务开启在Service层的方法上，Repository层保证一个方法内数据操作的原子性，但不跨多个Repo组合事务。这样更符合实际业务场景里“一个业务操作包含多个数据变更”的诉求。
如果业务需要同时更新订单和扣减库存，这两个动作不能在两个Repository里各开一个事务，而是应该在Service层用一个事物方法包裹。把事务边界下放到Repository层，会造成分布式事务问题的本地版本：每个Repo方法各自提交，中途失败就出现数据不一致。遇到这种情况，不要用“在Controller上开个事务”来解决，Controller开事务意味着一个HTTP请求的整个生命周期占用一个数据库连接，连接池再大也扛不住。
5.4 分层后接口返回结构不一致：统一返回结构的“最后一公里”
重构后容易出现一个新问题：接口明明分层了，每个方法返回的却还是一套“自定义结构”。有的直接返回String/Map，有的返回一个封装对象，有的返回Result，有的返回裸data，前端对接的时候苦不堪言。
我的方案是在Controller层统一用一个包装类型，Service层返回业务纯数据，Controller统一包装。包装类型的Response Code / Message / Data三件套，加上全局异常处理器，把业务异常、未知异常、校验异常统一归类输出。这样每层各司其职，对外协议永远稳定。
5.5 分层不是越多越好：常见“伪分层”误区的识别
实践中我见过把三层硬扩成五六层的项目：Controller、Service、Manager、Handler、Assembler、DAO。层数多了，每次业务改动要横向穿透五六个类，光是追踪代码就能消耗掉大半开发时间。
判断是否为“伪分层”，有个很简单的标准：如果迁移到一个方法，需要同时打开超过两个类的代码时，这层的存在意义就得打个问号。加层是手段不是目的。我个人的舒适区是3到4层，超过的话一定会有明显的收获（比如领域规则复用、存储抽象带来的切换能力），否则就砍掉。
6. 从分层到更高质量的代码设计
把分层落地落实之后，整个系统的可维护性曲线会变得平稳。后续还可以在这个基础上继续精进：把每个分层的接口契约文档化、给核心业务路径加更多的集成测试、把每层之间的DTO转换做成自动化映射等。
我在实际操作中的体会是，所有架构设计都可以总结成一句话：在做选择的时候，问问这种选择是让下一次改动变简单了，还是变复杂了。分层本身只是手段，一个团队真正需要的不是“标准架构图”，而是“面对业务变化时能够低成本地调整代码”的能力。哪怕暂时遵循的分层方案不完美，只要方向明确、约束清晰、团队共识达成一致，就已经赢过了绝大多数“代码没约束、全靠个人自觉”的项目。
最后再分享一个小技巧：每次代码评审的时候，可以让提交者标注自己这次改动分别落在哪几层。如果他吭哧了半天说不清楚，或者核心改动同时落在三层以上，大概率是这次改动边界有问题，值得停下来再聊一聊。这个小问题，背后往往藏着架构层面值得优化的信号。