前言在 Java 后端开发中采用经典的三层架构Controller - Service - DAO/Mapper是业界广泛接受的工程实践。这种分层结构通过职责分离提升了代码的可维护性、可测试性和可扩展性。然而在实际开发过程中一个常见且关键的设计问题常常困扰开发者在 Service 层中当需要访问其他模块的数据或功能时应该注入对应的 Mapper或 Repository/DAO还是注入另一个 Service这个问题看似简单但其背后涉及架构设计原则、职责边界划分、事务管理、代码复用性与系统耦合度等多个维度的考量。一、三层架构回顾职责与边界在典型的基于 Spring Boot MyBatis 的 Java Web 应用中三层架构的职责如下层级职责典型组件Controller 层接收 HTTP 请求参数校验调用 Service封装响应RestController, DTO, 参数校验注解Service 层实现核心业务逻辑协调多个数据操作管理事务Service,TransactionalDAO / Mapper 层封装数据库操作提供 CRUD 接口MyBatisMapper接口JPARepository关键原则每一层只应与其直接下层交互避免跨层调用如 Controller 直接调用 Mapper。二、Service 层的依赖注入选项当一个 Service例如OrderService需要访问其他实体如用户、商品、库存的数据或行为时它有两种主要的依赖注入选择注入目标实体的 Mapper如UserMapper注入目标实体的 Service如UserService这两种方式在语法上均可行但其适用场景和设计含义截然不同。三、何时注入 Mapper—— 数据访问的直接路径✅ 适用场景当你仅需读取或写入原始数据且不涉及目标模块的业务规则、校验、事务或副作用时应直接注入对应的 Mapper。 示例场景查询用户基本信息用于订单创建更新商品浏览次数记录操作日志到日志表批量插入中间表关联数据。 优势职责清晰Service 只负责自己的业务逻辑数据访问委托给 Mapper。性能高效避免不必要的方法调用栈和代理开销。低耦合不依赖其他 Service 的实现细节仅依赖数据结构。易于测试Mock Mapper 即可完成单元测试无需启动整个 Service 上下文。 代码示例ServicepublicclassOrderService{AutowiredprivateOrderMapperorderMapper;AutowiredprivateUserMapperuserMapper;// 直接注入仅用于查询用户是否存在publicvoidcreateOrder(CreateOrderDTOdto){// 仅验证用户是否存在无复杂业务逻辑UseruseruserMapper.selectById(dto.getUserId());if(usernull){thrownewBusinessException(用户不存在);}OrderordernewOrder();order.setUserId(dto.getUserId());order.setProductId(dto.getProductId());orderMapper.insert(order);}} 注意此处userMapper.selectById()仅返回数据不包含“激活用户”、“检查黑名单”等业务逻辑。四、何时注入其他 Service—— 复用完整业务逻辑✅ 适用场景当你需要复用目标模块封装好的完整业务行为包括但不限于数据校验如用户状态是否有效事务控制如库存扣减需回滚副作用处理如发送通知、记录审计日志状态机变更如订单状态流转权限或安全检查。此时应注入对应的 Service而非直接操作其 Mapper。 示例场景创建订单时需扣减库存库存服务包含超卖检查、事务、日志用户注册时需发送欢迎邮件邮件服务封装了模板、重试、异步支付成功后需更新会员等级等级计算涉及多张表和规则引擎。 优势逻辑复用避免重复实现相同业务规则符合 DRYDon’t Repeat Yourself原则一致性保障所有入口都走同一套业务流程确保系统状态一致可维护性高业务规则变更只需修改一处。⚠️ 注意事项避免循环依赖A Service 注入 BB 又注入 A会导致 Spring 启动失败或运行时异常事务传播行为需明确Transactional的传播机制如REQUIREDvsREQUIRES_NEW代理调用限制在同一个类中通过this.otherMethod()调用带事务的方法会绕过 Spring 代理应通过注入的 Bean 调用。 代码示例ServicepublicclassOrderService{AutowiredprivateOrderMapperorderMapper;AutowiredprivateInventoryServiceinventoryService;// 注入 Service因需完整业务逻辑TransactionalpublicvoidcreateOrder(CreateOrderDTOdto){// 检查用户可直接用 MapperUseruseruserMapper.selectById(dto.getUserId());if(usernull)thrownewBusinessException(用户不存在);// 扣减库存 —— 必须通过 Service因其包含// - 库存充足性检查// - 乐观锁更新// - 库存流水记录// - 可能触发补货通知inventoryService.deductStock(dto.getProductId(),dto.getQuantity());// 创建订单OrderordernewOrder(dto.getUserId(),dto.getProductId(),dto.getQuantity());orderMapper.insert(order);}}五、错误实践与反模式❌ 反模式 1为了“解耦”而强行通过 Service 访问简单数据// 错误示例UserService.getUserById() 仅返回 userMapper.selectById(id)UseruseruserService.getUserById(userId);// 无必要问题增加调用链深度引入无意义的 Service 层包装降低性能且若未来UserService添加了权限校验可能意外破坏OrderService的逻辑。❌ 反模式 2在 Service 中直接操作其他模块的 Mapper却忽略了业务规则// 危险示例直接更新用户余额userMapper.updateBalance(userId,newBalance);// 绕过了资金变动审计、风控等逻辑后果系统出现“幽灵资金变动”审计日志缺失违反金融合规要求。❌ 反模式 3Service 内部通过 this 调用自身带事务的方法ServicepublicclassOrderService{publicvoidmethodA(){this.methodB();// ❌ 不会触发 Transactional}TransactionalpublicvoidmethodB(){...}}正确做法通过 self-injection 或重构为两个 Service。六、决策流程图如何选择是否是否Service 需要访问其他模块?是否需要执行完整的业务逻辑?注入目标 Service是否仅需读写原始数据?注入目标 Mapper/Repository重新审视需求设计七、高级考量领域驱动设计DDD视角在更复杂的系统中可引入领域驱动设计DDD思想进一步指导分层聚合根Aggregate Root只有聚合根的 Repository 可被外部 Service 直接调用领域服务Domain Service跨聚合的业务逻辑应封装在领域服务中应用服务Application Service即传统 Service 层协调领域对象和基础设施。在此模型下跨聚合的数据访问必须通过领域服务或聚合根方法禁止直接操作其他聚合的 Mapper。虽然本文聚焦于传统三层架构但 DDD 提供了更高阶的解耦思路值得进阶开发者参考。八、总结Service 层应优先注入 Mapper 来访问数据仅当需要复用其他模块的完整业务逻辑时才注入其他 Service。具体判断标准如下判断维度注入 Mapper注入 Service目的获取/存储原始数据执行完整业务行为是否含业务规则否是是否含副作用否是如发消息、记日志是否需事务协调否是是否可能变更数据结构稳定业务逻辑可能演进