本篇要回答的问题：架构的第三步——详细设计到底该写什么？它和概要设计如何分工？为什么说"详细设计不是只谈实现、更不是一张架构图"，而应包含现状与需求 + 使用界面 + 实现（数据结构 + 算法）？
四部曲实战刚刚收官，本讲把视角从"具体怎么做"拉回到"方法论"：把需求分析（17/18）→ 概要设计（32）→ 详细设计这条主线补全。它正是对实战四讲所用方法的理论提炼。
三阶段的分工
| 阶段 | 关注点 | 核心产出 |
|---|---|---|
| 需求分析（17/18） | 用户需求精确表述：角色 + 用户故事 | 清晰的产品定义、边界、上下游分工 |
| 概要设计（32） | 以子系统为维度阐述角色关系；串联整个系统、消除重大风险 | 关键子系统的职责与接口（也应有代码产出） |
| 详细设计 | 各子系统/模块负责人对其负责部分进一步细化、谈全貌 | 现状需求 + 完整使用界面 + 实现原理 |
关键判断：概要设计与详细设计内容会重叠，但分工不同、重心不同——概要设计串系统、不把接口列全（只列最核心）；详细设计则要求接口描述的完备性是必需的。分解粒度也不能过粗，否则项目执行风险太高。
关键洞见：代码即文档，代码是理解一致性更强的文档——所以概要设计阶段也应有代码产出，一上来就消除全局系统性风险。
详细设计包含三块，缺一不可：
| 内容 | 回答的问题 |
|---|---|
| 现状与需求 | 现在在哪里、遇到什么问题、要做何改进 |
| 使用界面（接口） | 要做成啥样？交付物的规格 |
| 实现原理 | 怎么做到？数据结构 + 算法 |
现状与需求：简明扼要
关键判断：任何文档首先都应关注"要解决的问题与目标"。现状与需求都要简明扼要——现状大家都知道，别长篇累牍，只陈述与改变相关的重要事实、强调其存在性与重要性；需求是对痛点与改进方向的一次共识确认。
不必重做需求分析，但每个子系统/模块的角色分工与用户故事的核心结论，必须在详细设计前明确——这是详细设计要满足的业务目标。
使用界面（接口）：要详细写
关键洞见：使用界面体现"别人要怎么使用我"，应自然体现业务需求，并在需求分析→概要→详细之间保持自然的延续性。这一部分要详细写，它是团队共识确认的关键。
需明确：交付物有哪些可执行文件 / 包？是界面程序还是服务？服务就讲网络协议，包就列公开类与函数。
关键判断：使用界面的稳定至关重要，接口变更需谨慎！ 不兼容调整后果严重——技术上致客户编译失败、重写代码甚至系统崩溃；商业上可能导致大量客户流失。
实现：程序 = 数据结构 + 算法
数据结构
| 维度 | 桌面程序 | 服务端程序 |
|---|---|---|
| 主要数据结构 | 基于内存（外存仅限 IO 子系统） | 大多基于外存，且质量要求极高 |
| 谈的是什么 | 内存类/结构体设计 | 数据库表结构设计（mongodb 叫 Collection） |
关键判断：存储即数据结构——服务端最重要的是选对存储中间件，再在其上组织数据。这正是数据库流行的原因：它是泛业务场景的通用数据结构，业务适应性好。
描述表结构需含：字段名、类型、字段含义（是否指向另一表字段）、索引。它与定义内存类本质一致，唯一多出来的概念是索引：
| 索引为何存在 | 说明 |
|---|---|
| 数据库是泛业务通用结构 | 动态、需索引提升访问效率 |
| 多租户 | 数据爆发式增长，遍历查找不现实 |
关键洞见：索引怎么设计完全取决于算法——算法用了哪些数据访问特征、各特征频次预期多少，决定加哪些索引最划算。类多/表复杂时可用 UML 类图直观呈现。
算法
关键判断：算法就是用户故事背后的实现机制。需求分析的角色与用户故事，到详细设计阶段就变成了子系统/模块/类/函数的使用界面；数据结构 + 算法正是为满足最初的角色与用户故事定义。
描述算法的两种方式：
| 方式 | 适用 |
|---|---|
| UML 时序图（Sequence Diagram） | 交互步骤多、流程长时直观 |
| 伪代码（Pseudo Code） | 逻辑复杂时（如服务端复杂 SQL 操作，时序短但逻辑绕，画时序图意义不大） |
总结
本讲为"架构三部曲"补上最后一环：详细设计不是架构图、不是只谈实现，而是现状与需求（简明共识）+ 使用界面（详细、稳定、自然体现业务）+ 实现原理（数据结构 + 算法）。其中服务端数据结构本质是"存储选型 + 表结构 + 索引"，索引由算法决定；算法是用户故事的实现机制，用时序图或伪代码描述。它与前面实战四讲一脉相承、互为印证。
先把"是什么"回答清楚
| 概念 | 一句话说明 |
|---|---|
| 详细设计 | 对子系统/模块谈全貌：现状需求 + 完整接口 + 实现原理 |
| 现状与需求 | 简明陈述问题与目标，是对痛点的一次共识确认 |
| 使用界面 | 别人怎么用我，须详细且稳定，自然体现业务 |
| 存储即数据结构 | 服务端数据结构 = 存储选型 + 表结构 + 索引设计 |
| 算法 | 用户故事背后的实现机制，用时序图或伪代码描述 |
一句话速记
详细设计 = 现状需求（简明）+ 使用界面（详细且稳定）+ 实现（数据结构=存储选型+表+索引，算法=用户故事的实现机制）；代码即文档，接口变更需谨慎。
几条值得记住的判断
- 详细设计不是架构图、不是只谈实现——三块内容缺一不可。
- 接口稳定至关重要，不兼容变更技术上致系统崩溃、商业上致客户流失。
- 索引由算法决定，数据结构与算法本就一体两面。
思考题
本讲强调"使用界面的稳定至关重要、接口变更需谨慎"。回到你最近一次重构：你在详细设计里，是否把"现状与需求、完整接口、数据结构+算法"都写清楚了？还是只画了一张架构图就开干、结果在接口稳定性上栽了跟头？
