后端方案设计文档结构模板可参考

1 方案设计文档整体结构

一，现状：把项目的基本情况和背景都说清楚，让大家达成一个共识，才能进行后面的方案评审和讨论
    1、名词释义（方案设计到的术语、缩略词说明，解释时不要引入新名词）
    2、业务背景：业务（项目）的基本介绍
    3、技术背景：现有技术积淀、架构描述、系统的整体容量（可选，新系统不需要）
    
二，方案目标：技术方案一切都是围绕需求来设计，需求清楚之后才能比较好的去评审你的方案
    1、需求分析（如果有产品文档，直接从产品文档贴过来）
    	* 用户（角色、描述、预期）
    	* 用例图（需要与用户一一对应）
    2、需求列表
    	* 功能性需求列表（从用户角度的需求，不能是开发视角）
    	* 非功能性需求列表（性能需求、可用性需求、系统可观测性需求、数据量级评估，非常重要，这部分是业务方隐含的需求，不会明确告诉你，考虑到这部分能够提前识别风险，并且代码具备更强的健壮性可扩展性等）
    
三，架构设计（从抽象到具体，越靠近部署架构，越接近实际物理结构）
    1、业务架构（产品文档应该有，由产品提供，没有也得自己画）
		* 业务架构是业务视角的有哪些功能模块，与实际开发结构无关
		* 需要画出上下游业务功能模块，依赖的第三方功能模块、基础服务功能模块
		* 需要用颜色区分，让别人一眼就能看出你的业务模块
		* 维度是业务功能模块
    2、应用架构
		* 维度是微服务，一个微服务对应一个模块
		* 数据流向是纵向流动，从前端UI——负载均衡——网关——微服务——基础设施
		* 别人一看就知道，你这个服务由几个微服务组成
    3、部署架构
		* 与实际物理结构一致，数据流向接近物理结构，从UI——微服务——数据库
		* 别人一看，就能知道实际是怎么部署的
    
四，方案详细设计
    1、业务全流程
		* 展现了业务的全流程，给一个全局视角的业务流程
    2、业务实体结构
		* 需要把业务上下游的实体一起画出来，让人看到整体的数据流向
		* 注意，实体结构对应服务的实体抽象，与数据库表设计无关，不要冗杂数据库表的东西
    3、任务状态图
		* 重要实体类的状态流转
	4、核心子流程
		* 画核心流程的时序图，方便看清核心流程的细节
		* 最好所有流程都采用一致的时序图，保持结构的一致性
	5、存储设计
		* ER关系图
		* 数据库表设计
	6、接口设计
		* 可以贴上yapi接口文档，或者实际的接口设计
		* 粒度需要到接口的入参、出参
    
五，性能设计（对应非功能性需求，一个非功能性需求对应一个章节）

六，高可用设计
	1、模块高可用
		* 接入层，多节点部署服务
		* 服务间调用，超时控制与重试机制（熔断与降级）
		* 公共组件，比如配置热更新
		* 日志监控
		* 发布与运维
		* 基础设施
			* 数据库高可用与灾备，MySQL 主从架构（主备模式），支持定时快照与手动快照恢复
			* 缓存高可用，Redis 采用双副本部署模式（主从结构）
	2、依赖第三方服务的哪些接口及对应的熔断降级策略
		* 防止服务被第三方服务异常拉胯
		* 第三方服务、依赖接口、接口类型、依赖类型、接口用途、降级熔断措施

	
七，系统资源预估（用到了哪些资源，k8s、mysql、redis等资源预算）

    
八，工作量评估（可选）
	每个模块、每个接口的设计分别需要多长时间，一定要同时包括开发时间、联调时间、测试时间

---

2 模块详解及示例

这是一种自上而下的设计，需要从用户视角去看系统，从用户需求——>产品文档梳理——>功能设计——>代码开发，从业务架构进行下钻，进行更详细的设计，每一层级都基于上一层级所输出的内容，采用的是“结构化思维”

方案名称	xxxxxxx
方案作者	xxxxx
方案时间	xxxxx

2.1 方案背景

把项目的基本情况和背景都说清楚，让大家达成一个共识，才能进行后面的方案评审和讨论

2.1.1 名词释义

方案设计到的术语、缩略词说明，解释时不要引入新名词

术语 / 缩略词	说明
xxxx	xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxxx	xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxxx	xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxxx	xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxxx	xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

2.1.2 背景说明

当前业务痛点：

1、
2、
3、
4、

2.2 方案目标

2.2.1 需求分析

相关需求文档：

2.2.1.1 用户

如果有产品文档，直接从产品文档贴过来

角色	描述	预期
xxxx负责人	对xxxxx负责	期望能对xxxxx进行管理
xxxx管理员	对xxxxx负责	期望能对xxxxx进行管理
xxxx普通用户	对xxxxx负责	期望能对xxxxx进行管理

2.2.1.2 用例图

需要与上面的用户一一对应

• 对于这个服务系统，用户有哪些功能需求，分析之后输出用例图
• 这里的需求并非产品经理识别用户需求里面的用户需求，而是针对已有的产品文档输出开发的需求
• 根据所有用户的用例图，可以从中抽象出功能模块
• 示例：
  

2.2.2 需求列表

2.2.2.1 功能性需求列表

从用户角度的需求，不能是开发视角

需求分类	需求项	需求描述	备注
任务管理	创建任务	xxxxxxxx
	删除任务	xxxxxxxx
	查询任务列表	xxxxxxxx
	查询任务详情	xxxxxxxx
	修改任务	xxxxxxxx

2.2.2.2 非功能性需求列表

非常重要，这部分是业务方隐含的需求，不会明确告诉你，考虑到这部分能够提前识别风险，并且代码具备更强的健壮性可扩展性等

需求维度	需求	备注
性能	数据量级需要支持xxx级别
可用性	接口性能指标要求	关键性接口交互需求要求接口耗时秒级以内返回
系统SLA需求	系统支持99.9%—99.99%的高可用性
系统可观测性	业务层需求	任务进度可观测、系统日志、api接口监控

2.3 架构设计

从抽象到具体，越靠近部署架构，越接近实际物理结构

2.3.1 业务架构

• 从业务用户角度进行考虑，由哪些功能模块组成，https://zhuanlan.zhihu.com/p/342136194
• 业务架构是业务视角的有哪些功能模块，与实际开发结构无关
• 需要画出上下游业务功能模块，依赖的第三方功能模块、基础服务功能模块
• 需要用颜色区分，让别人一眼就能看出你的业务模块
• 维度是业务功能模块

例如：

2.3.2 应用架构

• IT系统功能和技术实现，从开发的角度来考虑功能模块与服务之间的关系,UI层、网关接入层、应用层、基础设施层
• 数据流向是纵向流动，从前端UI——负载均衡——网关——微服务——基础设施
• 维度是微服务，一个微服务对应一个模块，体现了微服务之间的关系
• 别人一看就知道，你这个服务由几个微服务组成
  

2.3.3 部署架构

• 服务之间如何进行部署，用户、网关、网络、防火墙、存储，从用户到存储的全部过程
• 与实际物理结构一致，数据流向接近物理结构。别人一看，就能知道实际是怎么部署的

2.3 详细设计

2.3.1 业务全流程

2.3.3 业务实体设计

• 核心功能涉及有哪些关键的类，这些关键类，又有哪些关键属性，实际上是为了梳理出类与类之间的关系，对应了写代码的思路
• 有了关键类，则可以为后续的存储设计，数据库表设计，进行参考
• 英文书写，类名最好直接对应与最后的开发类名

参考文档：http://www.objie.com/article/613ab8af0763c30011fa8daf

2.2.4 接口设计

2.3.3 任务状态图

2.3.3.1 同步任务状态图

2.3.4 业务核心子流程

根据需求分析得出的用例图，找到用例图中的核心功能，输出时序图，有时候业务的流程会比较复杂，涉及到多种角色，这时就可以使用时序图来梳理这个业务逻辑。这样会使业务看起来非常清晰。

• 通过时序图理清几个服务之间的交互关系，每一步的流程交互，在重要的地方可以尽量详细，也就是详略得当，对着就可以进行开发。

绘制参考文章：

• http://www.objie.com/article/6034b11a15c40100118fef6c
• https://www.cnblogs.com/54chensongxia/p/13236965.html

2.3.5 存储设计

2.3.5.1 ER关系图

2.3.5.2 任务表结构

2.3.6 接口设计

接口设计：xxxxxxxxx

2.4 性能设计

1、
2、
3、

2.5 高可用设计

2.5.1 模块高可用

模块	高可用设计目标	技术实现
接入层	请求入口稳定、支持大流量、防止单点故障	多节点部署接入服务
服务间调用	超时控制与重试机制	apisix配置请求超时时间，业务层添加重试机制（设置次数）
公共组件	配置热更新	使用配置中心（Apollo）统一管理配置信息
日志与监控	收集日志，快速定位问题
	指标监控，方便排查问题
发布与运维	快速部署、弹性伸缩、自动恢复	k8s滚动更新，一键回滚
基础设施（存储）	数据库高可用与灾备	MySQL 主从架构（主备模式），支持定时快照与手动快照恢复
	缓存高可用	Redis 采用双副本部署模式（主从结构）

2.5.2 第三方系统依赖接口

第三方系统	接口名称	接口方法	依赖类型	接口用途	降级熔断措施
xxx服务	/api/v2/xxxxx	GET	强依赖	xxxxx	快速失败 ,返回“服务暂不可用"。

2.6 系统资源评估

资源	规格	备注	使用评估
实例pod
mysql
redis