后端服务如何组织

后端不是“接收请求后查数据库”的一段代码，而是一组把输入变成可靠业务结果的边界。理解一次请求如何流动，比记住某个框架目录更重要。

一次请求的基本旅程

客户端请求
  → 路由与参数解析
  → 认证和权限检查
  → 业务服务与领域规则
  → 数据访问 / 外部服务
  → 响应、日志与指标

每一层回答不同的问题：路由决定入口；认证确认“你是谁”；授权确认“你能做什么”；业务服务决定规则；数据层负责持久化；边缘层把结果变成协议响应。

不要把所有逻辑塞进控制器

控制器或 handler 应保持薄：解析输入、调用业务服务、转换响应。业务规则放进可测试的服务层，数据查询放进仓储或模型层。

async function createOrderHandler(request) {
  const input = parseCreateOrder(request.body)
  const order = await orderService.create(input, request.user)
  return toOrderResponse(order)
}

这样同一套业务服务可以被 HTTP、定时任务、消息消费者等不同入口复用，规则也不会因为入口增加而复制。

同步路径只做用户正在等待的事

用户提交订单、保存资料等需要立即得到结果的操作，保留在同步请求中。发送通知、生成报表、同步非关键系统等耗时工作，适合进入可重试的异步任务。

放在请求内	放到后台任务
输入校验、权限判断、核心写入	邮件、推送、文件处理、批量同步
返回用户必须立即知道的结果	可延后、可重试、耗时较长的工作

异步不是“扔出去就不管”。任务需要状态、重试上限、失败告警和幂等策略。

组织服务时的检查表

• 输入是否在入口处校验并转成明确类型？
• 权限规则是否在业务操作前执行？
• 一次业务操作的事务边界是否清楚？
• 外部调用失败、超时或重复到达时会发生什么？
• 日志是否能关联到一次请求和一个业务对象？

服务边界清楚后，再讨论框架、数据库和部署方案，团队会有更稳定的共同语言。