文章目录分层架构DAO/Mapper/Repository/Service/Controller/Manager一、体系总览1.1 整体分层链路与上下游关系1.2 贯穿全体系的核心设计原则二、各组件深度结构化拆解2.1 Controller 层请求入口与流量网关核心职责设计原则与规范典型实现与误区边界关系2.2 Service 层核心业务逻辑编排层核心职责设计原则与规范典型实现与误区边界关系2.3 Manager 层通用原子能力封装层核心职责设计原则与规范典型实现与误区边界关系2.4 Repository 层DDD领域驱动仓储层核心职责设计原则与规范典型实现与误区边界关系2.5 DAO 层传统数据访问对象层核心职责设计原则与规范典型实现与误区边界关系2.6 Mapper 层ORM映射数据访问实现层核心职责设计原则与规范典型实现与误区边界关系三、核心易混淆组件横向对比3.1 DAO vs Mapper vs Repository 深度对比3.2 Service vs Manager 边界对比四、全链路调用流程与架构适配4.1 标准全链路执行流程4.2 不同架构体系下的组件适配五、最佳实践与避坑指南5.1 业界通用最佳实践5.2 高频错误避坑指南分层架构DAO/Mapper/Repository/Service/Controller/Manager一、体系总览1.1 整体分层链路与上下游关系这套组件是Java企业级开发Spring生态为主中实现分层架构、职责解耦、代码复用的核心功能单元完整的标准请求链路为客户端请求 → Controller → Service → Manager → Repository/DAO/Mapper → 数据库/第三方服务各组件按职责分为4个核心层级从上到下依赖关系单向传递禁止反向依赖与跨层调用层级分类包含组件核心定位入口层Controller系统对外门面请求流量的入口与出口业务层Service、Manager业务逻辑的核心承载Service负责流程编排Manager负责通用原子能力复用数据访问抽象层Repository、DAO业务与数据存储的解耦层Repository面向领域模型DAO面向数据库表数据访问实现层MapperORM框架对数据访问的具体实现直接与数据库交互1.2 贯穿全体系的核心设计原则单一职责原则SRP每个组件仅负责一类固定职责边界清晰避免万能类依赖倒置原则DIP上层仅依赖抽象接口不依赖底层具体实现实现解耦开闭原则OCP对扩展开放对修改关闭通过接口抽象适配变化迪米特法则组件仅与直接相邻的组件交互禁止跨层调用关注点分离业务逻辑、数据访问、请求处理、通用技术能力彻底分离降低系统复杂度二、各组件深度结构化拆解2.1 Controller 层请求入口与流量网关核心定义MVC架构中的控制器是HTTP/RPC请求的系统对外门面负责请求的接收、校验、路由与结果封装是客户端与系统内部的唯一交互入口。核心职责请求接收与路由匹配HTTP方法与URL路径接收路径变量、请求体、查询参数等基础参数校验完成非空、格式、长度、范围等无业务属性的参数合法性校验JSR-380规范协议转换将请求参数转换为业务层所需的DTO对象将业务结果封装为统一响应体流量与安全前置完成鉴权、限流、黑白名单等前置校验兜底异常处理特殊请求处理支持异步请求、文件上传下载、WebSocket等场景设计原则与规范瘦Controller原则绝对不包含业务逻辑仅做请求转发与结果封装无状态原则单例无状态禁止定义可变成员变量统一响应原则所有接口返回统一格式的响应体异常统一封装转换典型实现与误区典型实现Spring MVC的RestController/Controller注解高频误区在Controller中编写业务逻辑、直接调用DAO/Mapper跨层访问、参数校验缺失、原始异常直接抛出边界关系上游客户端浏览器、APP、第三方服务下游仅依赖Service层接口禁止依赖更下层组件2.2 Service 层核心业务逻辑编排层核心定义系统业务能力的核心载体是连接入口层与数据访问层的桥梁负责核心业务规则实现、业务流程编排与事务控制。核心职责核心业务规则实现封装业务领域的核心规则与校验如“下单时余额需大于订单金额”业务流程编排按业务场景编排多个原子操作的执行顺序如下单全流程事务管理定义事务边界保证多数据操作的原子性SpringTransactional依赖调度调用Manager层通用能力、Repository/DAO层数据访问能力完成业务业务异常处理抛出业务规则校验异常由Controller层统一封装返回设计原则与规范厚Service薄Controller原则核心业务逻辑必须下沉到Service层单一职责一个Service类仅负责一个业务领域避免万能Service面向接口编程必须定义接口上层仅依赖接口不依赖实现类无状态原则单例无状态禁止定义可变成员变量典型实现与误区典型实现SpringService注解采用接口实现类模式高频误区Service类代码臃肿、包含基础参数校验、直接操作数据库/第三方接口、事务控制不当大事务、事务失效、重复代码未下沉复用边界关系上游仅被Controller层依赖禁止反向依赖Controller下游依赖同领域其他Service接口、Manager层接口、Repository/DAO层接口2.3 Manager 层通用原子能力封装层核心定义Service层的“原子能力工具箱”位于Service层之下、数据访问层之上用于解决多Service通用逻辑复用、第三方系统交互隔离、复杂数据操作封装等问题中小项目可省略中大型/微服务项目强烈建议引入。核心职责通用逻辑复用封装多Service共用的原子逻辑如缓存操作、分布式锁、幂等处理、通用数据查询外部依赖隔离封装第三方系统/中间件调用支付网关、短信服务、Redis、MQ、RPC调用屏蔽底层实现变化复杂数据操作封装封装跨多Mapper的复杂查询、批量操作、数据聚合避免Service层直接操作多Mapper技术能力兜底统一实现重试、熔断降级、容错、日志埋点等非业务技术代码设计原则与规范原子性原则方法仅做一件事无业务流程编排业务编排必须在Service层通用性原则仅被单个Service使用的逻辑禁止放入Manager层无事务原则不控制事务边界仅被Service层的事务包含隔离性原则对上层屏蔽底层技术细节实现依赖解耦典型实现与误区典型实现SpringComponent注解如UserManager、CacheManager、SmsManager高频误区与Service职责混淆、在Manager中编写业务流程、反向依赖Service、与Mapper职责重叠、控制事务边界关系上游仅被Service层依赖禁止被Controller直接调用下游依赖DAO/Mapper/Repository、第三方系统、中间件2.4 Repository 层DDD领域驱动仓储层核心定义DDD领域驱动设计的核心组件是面向领域聚合根的对象集合管理抽象以“集合”的语义管理聚合根生命周期彻底屏蔽底层存储细节实现领域模型与数据存储的解耦。核心职责聚合根生命周期管理仅负责聚合根的新增、修改、删除、查询保证聚合根的完整性与不变性对象映射转换实现领域对象DO与持久化对象PO的双向转换隔离领域模型与数据库表结构存储细节屏蔽对领域层完全屏蔽底层存储实现MySQL、Redis、MongoDB等集合语义封装接口设计采用add()、remove()、getById()等集合操作语义而非数据库CRUD语义领域规则保障保证聚合根的业务不变量在持久化/查询时不被破坏设计原则与规范聚合根原则一个Repository仅对应一个聚合根聚合内部实体禁止独立创建Repository依赖倒置Repository接口放在领域层实现类放在基础设施层领域层仅依赖接口无业务逻辑原则禁止在Repository中编写业务规则业务逻辑必须在领域层实现典型实现与误区典型实现Spring Data JPA Repository接口DDD架构中接口位于domain层实现位于infrastructure层高频误区把Repository当成DAO使用、接口设计面向数据库CRUD、给非聚合根创建Repository、领域层依赖实现类、直接暴露PO对象给领域层边界关系上游被领域层的领域服务、应用服务对应传统Service依赖下游依赖底层DAO/Mapper、ORM框架、数据库屏蔽存储细节2.5 DAO 层传统数据访问对象层核心定义传统三层架构中数据访问层的经典抽象是Data Access Object数据访问对象设计模式的落地用于封装数据库操作隔离业务层与数据存储层。核心职责数据库操作封装封装单表的CRUD操作一个DAO对应一张数据库表数据访问细节隔离屏蔽JDBC连接、SQL执行、结果集处理、异常转换等底层细节SQL与代码分离管理SQL语句将SQL与Java业务代码解耦结果集映射将数据库结果集转换为PO对象反之亦然异常转换将底层SQLException转换为统一的数据访问异常屏蔽数据库厂商差异设计原则与规范单表原则一个DAO仅对应一张表禁止多表操作无业务逻辑原则仅做数据访问操作绝对不包含业务逻辑面向接口编程定义DAO接口业务层依赖接口不依赖实现类典型实现与误区典型实现基于JDBC、Spring JdbcTemplate的DAO模式Hibernate DAO实现高频误区在DAO中编写业务逻辑、一个DAO操作多张表、业务层直接写SQL跳过DAO层边界关系上游被Service/Manager层依赖禁止反向依赖上层下游直接操作数据库基于JDBC/数据库连接池实现2.6 Mapper 层ORM映射数据访问实现层核心定义以MyBatis为代表的ORM框架对DAO模式的现代化、轻量化实现是DAO层的主流落地形态通过注解/XML配置SQL与Java方法的映射自动处理参数绑定与结果集映射消除传统DAO的重复模板代码。核心职责SQL映射通过接口方法XML/注解映射对应的SQL语句实现数据库CRUD自动参数绑定自动将方法参数绑定到SQL占位符处理类型转换结果集自动映射自动将查询结果映射为PO对象支持一对一、一对多等复杂映射动态SQL管理提供动态SQL能力简化复杂条件查询的编写缓存管理提供一级/二级缓存优化查询性能设计原则与规范单表原则一个Mapper接口对应一张数据库表无业务逻辑原则仅做数据访问禁止包含业务逻辑SQL与代码分离复杂SQL建议写在XML文件中与Java接口分离细粒度原则方法粒度要细避免一个方法对应超级复杂SQL降低复用性典型实现与误区典型实现MyBatisMapper注解Mapper接口XML映射文件MyBatis-PlusBaseMapper高频误区编写复杂多表关联SQL导致维护困难、在Mapper中处理业务逻辑、滥用嵌套映射引发N1查询问题、跨层调用跳过Mapper直接执行SQL边界关系上游被DAO实现类、Manager、Service层依赖下游基于ORM框架封装JDBC直接操作数据库三、核心易混淆组件横向对比3.1 DAO vs Mapper vs Repository 深度对比对比维度DAO数据访问对象MapperORM映射RepositoryDDD仓储架构定位传统三层架构的数据访问抽象DAO模式的ORM具体实现DDD架构的领域存储抽象设计思想面向数据库表封装单表CRUD面向SQL映射简化JDBC模板代码面向领域聚合根模拟集合语义操作对象数据库表对应的PO对象数据库表对应的PO对象领域层的聚合根DO对象接口语义面向数据库insert、update、delete同DAO轻量化SQL映射面向集合add、remove、get、find核心目标隔离业务层与数据库消除DAO模板代码简化数据访问隔离领域层与存储实现领域模型解耦与业务耦合与业务逻辑解耦仅关注数据操作与业务逻辑解耦仅关注SQL映射与领域模型强绑定与业务语义对齐典型场景传统JDBC项目、轻量级项目绝大多数MyBatis/MyBatis-Plus项目DDD架构、复杂业务领域项目3.2 Service vs Manager 边界对比对比维度Service层Manager层架构定位核心业务逻辑编排层业务能力核心通用原子能力封装层Service的工具箱核心职责实现业务规则、编排业务流程、控制事务边界封装通用逻辑、第三方调用、中间件操作、复杂数据聚合设计原则面向业务场景一个Service对应一个业务领域面向通用能力一个Manager对应一类原子能力代码特性包含业务流程、多步骤编排、业务规则校验原子性、无业务流程、高复用性、无事务控制事务控制事务边界的定义者负责事务的开启与回滚不控制事务仅被事务包含可跨事务复用复用性业务场景专属复用性低通用能力可被多Service调用复用性高依赖方向依赖Manager、Mapper、同领域其他Service仅依赖Mapper、第三方系统、中间件禁止依赖Service是否必须分层架构核心必选层非必须中小项目可省略四、全链路调用流程与架构适配4.1 标准全链路执行流程客户端发送HTTP请求经过过滤器/拦截器完成认证、鉴权等前置处理请求路由到Controller层完成参数校验、协议转换Controller调用Service层接口传入DTO参数Service层完成业务规则校验编排业务流程控制事务边界Service调用Manager层的通用原子能力完成缓存、第三方调用、复杂数据查询等操作Manager/Service调用Mapper/DAO/Repository层执行数据库操作结果沿原链路逐层返回最终由Controller封装为统一响应体返回给客户端4.2 不同架构体系下的组件适配传统MVC三层架构表现层Controller业务层Service数据访问层DAO/Mapper适配可省略Manager层适合轻量级、业务简单的项目DDD领域驱动四层架构用户接口层Controller应用层ApplicationService对应传统Service仅做流程编排领域层DomainService核心业务规则、Repository接口基础设施层Repository实现类、Mapper、Manager通用能力适配以Repository为核心数据访问抽象Mapper作为底层实现适合复杂业务的中大型项目微服务分布式架构网关层统一入口替代Controller的鉴权、限流能力接口层ControllerRESTful接口、RPC API接口业务层Service业务编排、Manager封装RPC调用、分布式锁、分布式事务等分布式能力数据访问层Repository/Mapper适配分库分表、读写分离适配放大Manager层的作用实现分布式能力的统一封装与复用五、最佳实践与避坑指南5.1 业界通用最佳实践严格遵守分层边界禁止跨层调用严格遵循单向依赖规则分层校验原则Controller做基础格式校验Service做业务规则校验Mapper层不做校验数据对象隔离PO仅在数据访问层使用DTO用于前后端传输禁止PO直接暴露给前端通过MapStruct等工具实现对象转换事务精准控制事务边界仅在Service层定义事务内禁止RPC调用、缓存操作等非数据库操作避免大事务代码复用规范多Service通用逻辑下沉到Manager层多Manager通用逻辑封装为工具类禁止复制粘贴重复代码代码行数管控Controller建议≤300行Service≤500行Manager≤300行Mapper≤200行避免单类过度臃肿5.2 高频错误避坑指南分层混乱跨层调用禁止Controller直接调用Mapper即使简单CRUD也要经过Service层便于后续业务扩展职责错位代码臃肿禁止Controller写业务逻辑、Service写通用技术代码严格遵循“瘦Controller、厚Service、通用Manager”事务控制失效避免非public方法加Transactional、异常被捕获不抛出、事务内执行非数据库操作等场景SQL滥用性能问题Mapper以单表查询为主避免过度多表关联与嵌套映射防止N1查询问题对象混用安全风险禁止PO对象直接返回给前端避免数据库表结构泄露、敏感字段暴露Repository与DAO混淆DDD项目中必须严格遵守Repository的聚合根原则与集合语义禁止将Repository退化为DAOe