清洁架构下购票结账控制器实现的合规性及优化问询

背景 #

我正在开发一个活动购票结账路由的项目，现有控制器接收包含订单数据、客户信息、票务及支付详情的请求，并将其传递至用例处理。当前流程为：先通过用例创建Order实体，再将其传入另一个用例结合Tickets实体完成票务验证，验证通过后将Order传入支付用例生成Transaction实体，所有逻辑在同一控制器中实现，代码示例如下：

export class CheckoutController implements Controller {

  constructor(
   private createOrder: CreateOrder,
   private makeTicketValidate: MakeTicketValidate,
   private makePayment: MakePayment,
   ){}

  async handle (request: CheckoutController.Request): Promise<HttpResponse> {

     const order: Order = this.createOrder(request)
     // Here i receive the Order entity and step to the next use case

     const isValid: boolean = await this.makeTicketValidate(order)

     if(!isValid) {
       return badRequest()
     }
     
     const transactionId = await this.makePayment(order)

     if(!transactionId) {
       return internalServerError()
     }
    
     return ok({transactionId})
     
  }
}

疑问解答 #

1. 该控制器是否违反Clean Architecture原则？ #

目前的实现没有直接违反Clean Architecture核心原则，但存在优化空间。Clean Architecture要求控制器作为外层适配器，仅负责接收请求、调用用例、返回响应，不包含业务逻辑。你的控制器确实只是串联用例，没有嵌入业务规则，但问题在于它承担了业务流程编排的职责——也就是决定用例的执行顺序、失败分支处理，这部分逻辑其实属于业务层的"用例协调"范畴，而非控制器的职责。

2. 在控制器中传递Order实体在多个用例间是否属于代码异味？ #

不算代码异味，但要注意两点：

• 确保Order是领域实体（而非DTO），实体本身封装了业务规则，在各用例间传递是合理的，符合Clean Architecture中领域层作为核心的要求。
• 避免用例依赖控制器传递的实体状态做非预期修改，每个用例应仅对实体做自身职责范围内的操作，且操作需符合实体的业务规则。

3. 同一控制器中调用多个用例是否合理（尤其是单操作处理大量数据时）？是否应拆分控制器？ #

是否合理取决于业务场景：

• 如果"创建订单→验证票务→发起支付"是不可拆分的原子结账流程，那么在同一个控制器中调用多个用例是合理的，因为这是一个完整的业务操作。
• 如果后续可能出现单独执行某一步的需求（比如单独验证票务、单独发起支付），或者当前流程的复杂度持续上升（比如增加优惠券验证、库存扣减等步骤），则建议抽离出一个专门的业务协调用例（比如ProcessCheckout），让控制器只调用这一个协调用例，由协调用例内部去编排各个子用例的执行。此时不需要拆分控制器，而是拆分业务逻辑的编排职责。

4. 是否需通过Presenter返回数据，还是直接用用例返回结果生成HTTP响应？ #

建议使用Presenter，原因如下：

• 符合Clean Architecture的依赖规则：外层（控制器）依赖内层（用例），但用例不应知道外层的响应格式。Presenter作为适配器，负责将用例返回的领域对象/数据转换为HTTP响应格式，隔离业务逻辑和HTTP协议细节。
• 便于扩展：如果后续需要支持其他输出方式（比如WebSocket推送、消息队列通知），只需新增对应的Presenter，无需修改用例代码。
• 单一职责：控制器只负责请求转发和响应触发，Presenter负责响应格式处理，职责更清晰。

关于DAO和拆分控制器的建议 #

• DAO传递订单数据：不建议用DAO在各用例间传递数据。DAO是数据访问层的工具，用于和数据库交互，而用例间传递的应该是领域实体或DTO（数据传输对象）。如果担心实体传递带来的耦合，可使用DTO在不同用例间传输必要数据，但核心业务逻辑仍应基于领域实体。
• 拆分控制器：如前所述，若当前结账流程是完整原子操作，拆分控制器反而会增加复杂度。更合理的做法是抽离业务编排逻辑到专门的协调用例，保持控制器的简洁。只有当业务流程可以拆分为多个独立的HTTP操作时（比如单独的"创建订单"接口、"支付"接口），才需要拆分控制器。

内容的提问来源于stack exchange，提问作者Victor Antunes B.