订单取消逻辑应放在Order 领域对象（Domain Object）中，这是领域驱动设计（DDD）的核心原则。
一、三种放置位置的对比
| 位置 | 职责归属 | 问题 |
|---|---|---|
| Controller | 接收 HTTP 请求、参数校验、调用业务层 | 严重违反单一职责： - 混淆协议层与业务逻辑 - 无法复用（如 CLI/队列调用需重写） |
| Service | 协调多个领域对象、处理跨聚合事务 | 易沦为贫血层： - 若仅转发调用，逻辑仍散落在各处 - 业务规则不内聚 |
| Order 对象 | 封装订单自身行为与状态变更 | 符合充血模型： - 状态机集中管理 - 业务规则高内聚 |
✅核心原则：
“行为应靠近数据”—— 取消是订单自身的状态变更，理应由 Order 对象负责。
二、正确实现：Order 对象作为行为载体
1.Order 领域对象（充血模型）
classOrder{privatestring$status;private\DateTimeImmutable$createdAt;publicfunction__construct(){$this->status='pending';$this->createdAt=new\DateTimeImmutable();}// 核心业务逻辑publicfunctioncancel():void{if($this->status!=='pending'){thrownewDomainException('Only pending orders can be cancelled');}if($this->createdAt<new\DateTimeImmutable('-30 minutes')){thrownewDomainException('Cancellation window expired');}$this->status='cancelled';// 触发领域事件（可选）DomainEvent::dispatch(newOrderCancelled($this->id));}publicfunctionisCancelled():bool{return$this->status==='cancelled';}}2.Service 层（协调者角色）
classOrderService{publicfunction__construct(privateOrderRepository$orders,privateInventoryService$inventory){}publicfunctioncancelOrder(int$orderId):void{$order=$this->orders->findById($orderId);if(!$order)thrownewOrderNotFound();// 执行核心逻辑$order->cancel();// 协调外部服务$this->inventory->releaseStock($order->getItems());// 持久化$this->orders->save($order);}}3.Controller（纯协议适配）
classOrderController{publicfunctioncancel(Request$request,int$id){try{$this->orderService->cancelOrder($id);returnresponse()->json(['status'=>'cancelled']);}catch(DomainException$e){returnresponse()->json(['error'=>$e->getMessage()],400);}}}三、为什么 Order 对象是最佳位置？
1.状态机内聚
- 订单状态规则（
pending → cancelled）集中在一处 - 避免在 Controller/Service 中重复写
if ($status !== 'pending')
2.高可测试性
// 测试订单自身行为（无需框架）publicfunctiontest_cannot_cancel_paid_order(){$order=newOrder();$order->pay();// 假设已支付$this->expectException(DomainException::class);$order->cancel();}3.多入口复用
- Web 请求、CLI 命令、消息队列消费者均可调用
$order->cancel() - 无需复制业务逻辑
4.符合 DDD 聚合根原则
- Order 是聚合根（Aggregate Root）
- 所有状态变更必须通过聚合根方法
四、常见误区与陷阱
| 误区 | 后果 | 修正 |
|---|---|---|
| 在 Controller 直接改状态 | 逻辑散落，无法复用 | 提取到 Order 对象 |
| Service 包含所有逻辑 | Order 成为数据容器（贫血模型） | 将状态规则移回 Order |
| 用 Eloquent Model 代替 Order | 混淆持久化与领域逻辑 | 分离 Entity 与 Eloquent Model |
| 忽略领域事件 | 库存释放等副作用难追踪 | 在 cancel() 中触发事件 |
⚠️Laravel 特别警告：
若直接使用 Eloquent Model：// 错误！Active Record 模式阻碍领域建模classOrderextendsModel{publicfunctioncancel(){$this->status='cancelled';// 无业务规则校验$this->save();}}必须引入纯 PHP 领域对象，Eloquent 仅作数据映射。
五、工程实践建议
分层清晰：
- Domain Layer：Order 实体 + Repository 接口
- Application Layer：OrderService（用例协调）
- Infrastructure Layer：EloquentOrderRepository（实现）
状态变更原子性：
- 所有状态修改在 Order 方法内完成
- Service 层统一事务（
DB::transaction()）
防御性编程：
- Order 方法抛出DomainException（非通用异常）
- Controller 捕获并转换为 HTTP 错误
总结
- Order 对象：存放“能否取消”的业务规则（状态机、时间窗口）
- Service 层：处理“取消后做什么”（释放库存、发通知）
- Controller：仅做协议转换（HTTP ↔ 领域）
💡终极心法：
当你的业务逻辑需要回答“为什么不能这样做”时，它就该在领域对象里。
订单取消不是“把 status 改成 cancelled”，而是“在特定条件下允许状态迁移”—— 这是 Order 自己的职责。
