Java三层架构中Service与Mapper注入策略解析

1. 问题背景与核心矛盾

在Java后端开发的三层架构实践中，Service层作为业务逻辑的核心载体，经常需要与其他模块进行交互。这种交互方式的选择——是直接注入Mapper操作数据，还是通过其他Service复用业务逻辑——看似是一个简单的技术选型问题，实则关系到整个系统的可维护性和架构健康度。

我经历过一个电商项目重构，最初团队为了"保持一致性"，强制要求所有跨模块调用必须通过Service层。结果导致：

• 简单的用户信息查询需要穿透3层调用栈
• 修改一个基础字段可能引发意料之外的业务校验
• 单元测试需要Mock大量无关的Service依赖

后来我们调整策略，严格区分"数据访问"和"业务复用"场景，系统复杂度立即下降了40%。这个案例让我深刻认识到：依赖注入的选择本质上是对模块边界的定义。

2. 架构原则与设计考量

2.1 分层架构的本质价值

经典三层架构的核心价值在于关注点分离：

• Controller：处理协议转换和输入输出
• Service：封装业务规则和流程
• Mapper：实现数据持久化细节

这种分层带来的直接好处是：

1. 变更隔离：数据库schema变化只需调整Mapper
2. 测试便利：业务逻辑测试可以Mock数据层
3. 复用灵活：相同业务规则可被不同入口调用

2.2 依赖方向的黄金法则

健康的依赖关系应该遵循：

1. 单向依赖原则：高层模块可以依赖低层模块，反之则禁止
2. 稳定依赖原则：依赖方向指向更稳定的模块（业务规则比数据存储稳定）
3. 明确边界原则：模块间通过定义良好的接口通信

实际案例：在支付系统中，支付核心服务（稳定）不应依赖优惠券服务（易变），而应通过抽象接口交互。

3. 注入Mapper的适用场景

3.1 典型使用场景

以下情况应优先考虑注入Mapper：

1. 只读数据访问：查询商品基础信息展示
2. 批量数据操作：导出报表时的大批量数据查询
3. 中间表处理：订单-商品关联表的维护
4. 监控统计：需要直接访问原始数据的分析场景

3.2 性能优化实践

在秒杀系统中，我们通过直接注入Mapper获得了显著性能提升：

java复制@Repository
public interface SeckillMapper {
    @Update("UPDATE stock SET count = count - 1 WHERE product_id = #{productId} AND count > 0")
    int reduceStock(@Param("productId") Long productId);
}

@Service
public class SeckillService {
    private final SeckillMapper seckillMapper;
    
    public boolean trySeckill(Long productId) {
        return seckillMapper.reduceStock(productId) > 0;
    }
}

这种写法相比通过库存服务调用：

1. 减少50%的方法调用开销
2. 避免不必要的业务校验
3. SQL直接使用乐观锁保证原子性

3.3 事务处理技巧

即使直接使用Mapper，仍可通过声明式事务保证一致性：

java复制@Transactional
public void processOrder(Order order) {
    orderMapper.insert(order);
    // 直接操作日志表Mapper
    logMapper.insert(new OperationLog("CREATE_ORDER", order.getId()));
    // 更新统计信息
    statsMapper.incrementOrderCount(order.getUserId());
}

关键点：

• 使用@Transactional注解统一管理事务
• 所有Mapper操作在同一个事务内
• 避免在事务内进行远程调用

4. 注入Service的合理场景

4.1 必须使用Service的情形

当遇到以下业务需求时，应该选择注入Service：

1. 复合业务规则：用户注册需要验证手机号、初始化账户、发送欢迎包
2. 状态机管理：订单状态从"待支付"到"已支付"的转换
3. 分布式事务：跨服务的业务一致性保证
4. 安全审计：需要记录完整操作链的场景

4.2 领域驱动设计实践

在供应链系统中，我们采用领域服务封装核心逻辑：

java复制@Service
public class InventoryService {
    @Transactional
    public void allocateStock(AllocationCommand command) {
        // 检查库存可用性
        Inventory inventory = inventoryRepository.findById(command.productId());
        if (!inventory.canAllocate(command.quantity())) {
            throw new BusinessException("库存不足");
        }
        
        // 执行分配
        inventory.allocate(command.quantity());
        inventoryRepository.save(inventory);
        
        // 记录分配日志
        allocationLogService.logAllocation(command);
        
        // 触发补货检查
        if (inventory.needReplenishment()) {
            replenishmentService.requestReplenishment(command.productId());
        }
    }
}

这种封装保证了：

1. 库存分配的业务规则集中维护
2. 相关副作用统一处理
3. 事务边界明确

4.3 服务调用的注意事项

1. 循环依赖解决方案：

   • 使用@Lazy延迟注入
   • 提取公共逻辑到新服务
   • 采用事件驱动架构

2. 事务传播行为选择：

   • REQUIRED（默认）：加入当前事务
   • REQUIRES_NEW：新建独立事务
   • NOT_SUPPORTED：非事务方式执行

3. 性能优化建议：

   • 对只读操作使用@Transactional(readOnly = true)
   • 批量操作考虑PROPAGATION_NESTED

5. 复杂场景的决策框架

5.1 四象限决策法

根据业务复杂度和数据访问模式，可以将决策分为四个象限：

5.2 事务边界评估流程

1. 确认操作是否影响多个聚合根
2. 检查是否需要维护业务不变式
3. 评估是否会产生业务事件
4. 判断是否需要保证最终一致性

5.3 性能与一致性权衡

在高并发场景下，可以采用折中方案：

java复制public class OrderService {
    private final OrderMapper orderMapper;
    private final InventoryClient inventoryClient; // 防腐层
    
    public void createOrder(Order order) {
        // 快速路径：直接检查库存可用性
        if (inventoryMapper.getAvailableStock(order.getProductId()) < order.getQuantity()) {
            throw new BusinessException("库存不足");
        }
        
        // 慢速路径：通过服务完成最终预留
        inventoryClient.reserveStock(order.getProductId(), order.getQuantity());
        
        orderMapper.insert(order);
    }
}

6. 测试策略差异

6.1 Mapper注入的测试优势

java复制class OrderServiceTest {
    @Mock
    private OrderMapper orderMapper;
    @Mock
    private UserMapper userMapper;
    
    @Test
    void shouldCreateOrderWhenUserExists() {
        when(userMapper.selectById(any())).thenReturn(new User());
        when(orderMapper.insert(any())).thenReturn(1);
        
        service.createOrder(new CreateOrderDto(1L, 1001L));
        
        verify(orderMapper).insert(any());
    }
}

特点：

• 测试类只关注自身业务逻辑
• Mock设置简单直接
• 执行速度快（平均<50ms/测试）

6.2 Service注入的测试挑战

java复制class PaymentServiceTest {
    @Mock
    private OrderService orderService;
    @Mock
    private AccountingService accountingService;
    
    @Test
    void shouldProcessPaymentSuccessfully() {
        when(orderService.lockOrder(any())).thenReturn(new Order());
        when(accountingService.debit(any(), any())).thenReturn("TX123");
        
        PaymentResult result = service.processPayment(new PaymentRequest());
        
        assertThat(result.getStatus()).isEqualTo(SUCCESS);
        verify(orderService).completeOrder(any());
    }
}

注意点：

• 需要理解被依赖服务的契约
• 可能涉及事务传播行为验证
• 考虑使用集成测试补充验证

7. 演进式架构建议

7.1 从简单到复杂的演进路径

1. 初期：直接使用Mapper快速实现功能
2. 中期：识别重复逻辑，提取到Service
3. 后期：引入防腐层隔离领域模型

7.2 识别重构信号

• 相同数据操作出现在多个Service中
• Mapper方法参数超过3个
• 需要修改多个Mapper来满足业务需求
• 事务注解传播属性变得复杂

7.3 模块化进阶方案

对于大型系统，建议采用：

java复制// 领域模块内部
class OrderService {
    private final OrderRepository orderRepository; // 聚合根仓库
    
    public void cancelOrder(Long orderId) {
        Order order = orderRepository.findById(orderId);
        order.cancel(); // 领域行为
        orderRepository.save(order);
    }
}

// 跨模块交互
class OrderFacade {
    private final OrderService orderService;
    private final InventoryClient inventoryClient;
    
    @Transactional
    public void cancelOrderWithRestock(Long orderId) {
        Order order = orderService.cancelOrder(orderId);
        inventoryClient.restock(order.getProductId(), order.getQuantity());
    }
}

在实际项目中，我逐渐形成了这样的经验法则：当你在编写Service方法时，如果发现自己在"猜测"另一个模块的内部逻辑，就应该注入它的Service；如果只是需要它的数据，就直接用Mapper。这个简单的判断标准帮助我避免了许多设计错误。