三层架构重构实录：我是如何把500行Controller拆干净的

接手老项目时看到个"巨无霸"Controller，一个index方法足足500行代码，各种业务逻辑、数据校验、日志记录全揉在一起，改个需求就像在面条代码里找线头。这次重构我做了三件事：

1. Controller只做三件事：
- 接收请求参数（过滤XSS+基础校验）
- 调用对应Service
- 返回统一格式响应
把原来糅在Controller里的优惠券计算逻辑、库存校验统统抽到Service层

2. Service层严格遵循单一职责：
- 每个Service方法对应一个完整业务单元
- 使用DTO对象传递参数避免参数爆炸
- 事务控制放在这一层（避免在Controller里开事务）
比如把原来的订单创建拆成OrderCreateService，内部再细分为库存服务、优惠服务、支付服务三个子模块

3. Model层瘦身成纯数据管家：
- 只保留基础的CRUD操作
- 字段修改器/访问器移到Service层
- 关联查询用查询构造器单独处理
原来在Model里写的好几个自定义scope方法，现在改用Repository模式集中管理

踩坑提醒：
- 不要为了分层而分层（简单CRUD可以直接Model调用）
- Service之间避免环形调用（我的优惠服务调支付服务，支付服务又回调优惠服务，直接死循环）
- 跨服务操作记得加@Transactional注解（血的教训：本地测试OK，线上并发出现数据不一致）

重构后虽然多了十几个文件，但改需求时终于不用在屎山里淘金了。特别当需要加个新支付方式时，直接在PayService里新建策略类就行，原来要改三四处的逻辑现在只需动一个文件。