业务插件开发：如何用Service层吃掉Controller的胖逻辑？

最近重构老插件时发现Controller里堆了300行业务逻辑，连Redis操作和PDF生成都塞在里面。分享下我们的分层改造方案：

1. Controller瘦身黄金法则：

// 反面教材
public function orderCreate() {
    // 参数校验
    // 风控检查
    // 库存计算
    // 优惠券核销
    // 订单持久化
    // 短信通知
    // ......
}

// 改造后
public function orderCreate() {
    $params = $this->validate();
    return $this->orderService->create($params); 
}

2. Service层拆解技巧：

• 按业务域划分子Service（PaymentService/InventoryService）
• 公共逻辑抽离到Helper层（如ExcelExportHelper）
• 领域对象作为参数传递而非数组（避免到处写$data['order_id']）

3. Model层该不该背锅？

常见误区是把Service逻辑下沉到Model，结果变成：

// 过度赋能的Model
$user->calculateLoyaltyPoints();
$user->sendBirthdayCoupon();

我们的实践：
• Model只做数据存取和简单计算
• 跨表操作交给Service
• 领域事件触发放在Service

改造后代码可测试性明显提升，Mock服务时不再需要启动全套HTTP请求。你们的分层边界是怎么划定的？