订单与支付CASE 01
用户点击“提交订单”后，后端承担哪些工作？
用户正在做什么
用户选择地址、优惠券和支付方式后提交订单。
业务会出什么问题
价格可能变化、库存可能不足、优惠券可能失效，外部支付也可能不可用。
技术怎样介入
后端验证身份、重新计算金额、检查库存、创建订单、调用支付并记录结果。
产品与设计怎样落地
页面需要区分库存不足、价格变化、优惠失效、支付创建失败和结果确认中。
M2 · Chapter 03
后端与业务逻辑
理解 API 后面的代码如何组织，以及 Service 真正负责什么。
先看哪些场景
订单与支付、消息与通知、项目与协作、账号与权限、文件与 Excel
它是什么
后端是运行在服务器上的应用，负责身份、权限、业务规则、数据访问和外部系统协作。
为什么需要
页面背后的限制、流程和状态大多由后端决定，理解后端后才能看懂真实业务系统。
位于哪一层
位于 API 入口与数据能力之间，是业务逻辑的执行中心。
和谁连接
Controller、Service、Repository、Entity、Middleware、Validation、数据库与第三方 API。
项目里怎么出现
创建订单、审批流程、权限判断、计费和导出任务都由后端组织。
Learning Outcomes
学完这一章，你应该能
- 理解后端的职责边界
- 看懂 Controller—Service—Repository 分层
- 区分业务对象、接口结构和数据库模型
- 理解中间件、校验与错误处理
03.01
后端到底负责什么？
后端把用户请求转化为受规则约束的业务结果。
Business Scenario First
先从真实业务问题进入
先看用户动作和业务风险，再理解技术为什么出现，以及它会怎样改变页面、状态和流程。
后端验证身份与权限，检查输入，执行业务规则，读写数据库，调用支付、短信或 AI 等外部服务，并返回稳定的数据结构。
前端可以隐藏按钮，真正的权限仍要由后端判断。价格计算、状态流转和审批条件也应放在可信的服务端环境。
API Request → Auth → Validation → Business Logic → Data / External Service
System View
接收请求
→
确认身份
→
校验输入
→
执行业务
→
读写数据
→
返回结果
Designer Lens
界面规则需要区分展示层约束与真正的业务约束，后者必须由后端兜底。
BackendBusiness LogicExternal Service
03.02
语言和框架只是实现入口
Java、Node.js、Python、Go 等生态都可以构建相似的后端职责。
Business Scenario First
先从真实业务问题进入
先看用户动作和业务风险，再理解技术为什么出现，以及它会怎样改变页面、状态和流程。
消息与通知CASE 01
短信通知服务用 Java、Python 还是 Node.js，用户会感知吗？
用户正在做什么
订单完成后系统需要发送短信、邮件和站内信。
业务会出什么问题
团队容易把技术选型当成产品能力本身，忽略接口契约、可靠性和现有运维体系。
技术怎样介入
不同语言运行在各自 Runtime 中，框架组织接口与依赖；依赖注入便于替换短信供应商和测试。
产品与设计怎样落地
产品设计关注发送状态、失败重试和替代通道，底层语言通常不影响交互。
Spring Boot、NestJS、FastAPI、Django 和 .NET 提供路由、依赖注入、数据访问和安全等框架能力。技术栈会影响性能、团队招聘和生态工具。
学习全景时先看共同结构：请求进入、业务组织、数据访问、异常处理和部署。掌握这些结构后，切换语言更容易定位概念。
HTTP Server → Framework → Application Modules → Runtime
System View
Java / Spring Boot
TypeScript / NestJS
Python / FastAPI
Go / Gin
C# / .NET
PHP / Laravel
Designer Lens
开发会议里听到技术栈时，先判断它解决的是语言、框架、数据库还是运行环境。
RuntimeFrameworkDependency Injection
03.03
Controller、Service、Repository
分层让请求入口、业务规则和数据访问各自保持清晰职责。
Business Scenario First
先从真实业务问题进入
先看用户动作和业务风险，再理解技术为什么出现，以及它会怎样改变页面、状态和流程。
订单与支付CASE 01
一笔退款请求在后端如何分层处理？
用户正在做什么
客服在订单详情点击退款并填写原因。
业务会出什么问题
接口接收、退款规则、数据库读取和第三方支付调用混在一起，会难以测试和维护。
技术怎样介入
Controller 读取请求，Refund Service 检查状态和金额，Repository 查询订单并保存退款记录。
产品与设计怎样落地
设计流程时把业务规则与接口状态对应起来，例如“已发货不可直接全额退款”。
Controller 读取 HTTP 参数并调用业务；Service 组织完整业务流程；Repository 负责查询和写入数据库。分层让规则更容易复用、测试和修改。
ProjectService.createProject 可能检查成员权限、生成编号、创建默认阶段、记录日志和发布事件。它调用多个 Repository 或其他 Service 完成任务。
Request → Controller → Service → Repository → Database
System View
Controller：接口入口
Service：业务规则
Repository：数据访问
Database：数据持久化
Designer Lens
设计流程图中的业务步骤，往往会在 Service 层变成可执行规则。
常见混淆 · Service 是否等于微服务？
Service 层是代码组织概念；微服务是系统部署和边界概念。一个单体应用内部也可以有很多 Service。
ControllerService LayerRepository
03.04
Model、Entity、DTO 与 Schema
同一业务对象在不同边界会有不同数据表达。
Business Scenario First
先从真实业务问题进入
先看用户动作和业务风险，再理解技术为什么出现，以及它会怎样改变页面、状态和流程。
项目与协作CASE 01
“项目”在页面、接口和数据库里为什么长得不完全一样？
用户正在做什么
新建项目表单只提交名称和负责人，详情页却要展示成员数、风险数和创建人信息。
业务会出什么问题
直接把数据库 Entity 原样返回，会泄露内部字段，也难以适配不同页面的数据需求。
技术怎样介入
Entity 对应持久化对象，DTO 定义接口输入输出，Schema 约束字段类型和必填规则。
产品与设计怎样落地
设计数据结构时区分用户输入、页面展示、系统生成和敏感字段。
Entity 常对应数据库中的核心业务实体；DTO 定义接口输入和输出；Schema 描述字段类型和约束；View Model 可以专门适配页面展示。
直接把数据库所有字段返回给前端会泄露内部结构，也会让接口跟数据库紧密耦合。清晰的转换层可以保护边界。
Database Entity ↔ Domain Model ↔ DTO ↔ Frontend View Model
System View
内部数据
- 主键与外键
- 审计字段
- 内部状态
- 敏感信息
接口数据
- 页面需要字段
- 明确枚举与格式
- 隐藏敏感内容
- 稳定版本契约
Designer Lens
页面字段不一定等于数据库字段。设计师可以先描述用户需要的信息，再与开发确定接口结构。
EntityDTOSchema
03.05
Middleware 与横切能力
很多通用处理会在请求进入业务前后统一执行。
Business Scenario First
先从真实业务问题进入
先看用户动作和业务风险，再理解技术为什么出现，以及它会怎样改变页面、状态和流程。
账号与权限CASE 01
为什么每个接口都能统一检查登录和请求频率？
用户正在做什么
用户连续调用导出接口，系统需要验证登录、限制频率并记录请求链路。
业务会出什么问题
把相同逻辑复制到每个 Controller 会造成遗漏和规则不一致。
技术怎样介入
Middleware 在请求进入业务逻辑前统一执行认证、Rate Limit，并生成 Trace ID。
产品与设计怎样落地
当请求被限制或登录过期时，页面要显示剩余等待时间和重新登录入口。
日志、身份认证、请求追踪、限流、跨域和异常转换都可以通过 Middleware 或拦截器统一处理。这样每个 Controller 无需重复实现。
执行顺序很重要：先生成请求 ID，再记录日志，再验证身份，随后进入业务。响应返回时也可以统一补充 Header 或转换错误格式。
Request → Trace → Log → Auth → Rate Limit → Controller
System View
请求进入
→
追踪 ID
→
日志
→
认证
→
限流
→
Controller
→
统一响应
Designer Lens
统一错误结构可以让前端建立稳定的 Toast、表单错误和重试逻辑。
MiddlewareRate LimitTrace ID
03.06
Validation、错误处理与幂等
系统需要明确什么输入合法、失败如何表达、重复请求如何处理。
Business Scenario First
先从真实业务问题进入
先看用户动作和业务风险，再理解技术为什么出现，以及它会怎样改变页面、状态和流程。
订单与支付CASE 01
用户连续点击支付，为什么不会扣两次钱？
用户正在做什么
支付按钮响应变慢，用户连续点击两次；客户端也可能因网络超时自动重试。
业务会出什么问题
后端可能创建两笔支付单、重复扣款或重复发放权益。
技术怎样介入
客户端为一次业务操作生成幂等键，服务端记录处理结果；相同键再次到达时直接返回原结果。
产品与设计怎样落地
按钮点击后立即进入处理中；超时提示“正在确认支付结果”，提供查询结果，避免直接引导再次支付。
文件与 ExcelCASE 02
一万行导入中有三行格式错误，系统怎样反馈？
用户正在做什么
运营上传客户名单，其中部分手机号和日期格式不合法。
业务会出什么问题
缺少 Validation 会把脏数据写入系统；统一显示“导入失败”又无法帮助用户修复。
技术怎样介入
Schema 校验字段并生成结构化错误码，服务端返回错误行、字段和原因。
产品与设计怎样落地
设计部分成功、错误报告下载、修复后重试和是否回滚全部数据。
Validation 检查必填、格式、范围和业务前置条件。错误应有稳定代码、可读消息和必要上下文，避免所有失败都返回同一个 500。
支付、创建订单等操作需要考虑重复点击和网络重试。幂等设计让同一个请求执行多次仍保持预期结果。
Input → Validation → Business Check → Idempotency → Result / Error
System View
输入错误
- 字段缺失
- 格式不对
- 范围不合法
- 返回 400/422
业务冲突
- 状态已变化
- 资源已存在
- 重复请求
- 返回 409 或业务错误码
Designer Lens
禁用按钮只能减少重复操作，后端仍需要处理重复请求和并发。
ValidationIdempotencyError Code
Chapter Recap
本章小结
- 01后端执行身份、权限、业务和数据处理。
- 02Controller、Service、Repository 分别负责入口、规则和数据访问。
- 03Entity、DTO 与 Schema 保护不同层之间的边界。
- 04中间件、校验、错误和幂等让系统更稳定。
Practice
把认知变成一张图
为“提交报销”画出 Controller、Service、Repository 的职责，并列出三种可能的业务错误。
Quick Check
随堂检查
QUESTION 01
ProjectService.createProject 最适合放在哪一层？
完整业务规则由 Service 层组织。
QUESTION 02
为什么前端隐藏按钮仍不足以保证权限？
可信权限判断必须在后端执行。