PHP订单取消逻辑，该放在 Controller、Service 还是 Order 对象中？-洪萨配资

订单取消逻辑应放在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 错误