技术文档模板

1. 修改历史

2. 概述

2.1 术语

如果在PRD文档中已经定义了某一个术语，建议在此处引用定义，以确保本文档的阅读者能够在一篇文档中就可以了解所有的关键术语。

2.2 需求背景

需求提出者（产品经理）需要提供项目要解决的问题，后续的规划和意义等。可以从PRD或者项目启动会议的文档中获取。

2.3 目标

本次迭代需要取得的项目和业务目标，项目目标包括上线时间，系统稳定性等，业务目标主要是项目组所承担的业务KPI

3. 系统架构与领域模型

3.1 架构分析

如果本次开发内容是项目的首次开发或者是大规模的重构，则需要重点在本小节描述整体的技术架构规划，包括业务架构、技术架构、应用架构、数据架构、物理架构等模块。 如果开发的内容是在原有系统上添加功能，需要引用原有系统的系统架构，帮助文档阅读者理解本次修改是否存在架构上的调整。

3.2 领域模型

系统模型的静态视图，表现各个业务模型直接的关系，关系包括，依赖，关联，组合，聚合，实现，泛化 等，可用类图表达，希望能以DDD的思想来表达业务的领域模型，这里需要交代清楚系统涉及到的领域模型的具体情况，除了关系之外，尽可能的表达领域的核心属性和事件。

4. 用例分析

4.1 业务用例分析

业务用例主要来自PRD中需要完成业务功能而分解出来的用例，比如我们常见的登录、注册、找回密码等，业务用例会有参与者，即使用我们的系统的用户，这里既可以是人，也有可能是系统。最终需要表述的就是参与者与用例的关系。

4.2 系统用例分析

系统用例主要是为了实现业务用例，我们设计出来的应用、服务、接口等内容。

4.3 边界分析

本小节主要描述上述系统用例之间的边界问题，简单可以理解为哪些接口应该放在哪些应用中，这些接口的上下游依赖关系是什么。

5. 业务变更影响

5.1 原业务影响分析

这里需要描述本次变更对原有业务的影响，重点是业务影响，而不是应用和系统的影响，比如费率调整需要由实时生效变更为次日生效，影响到的业务包括司南开户、费率获取等。

5.1.1 影响业务1

5.1.2 影响业务2

5.2 业务兼容性分析

本节分析接口的变更是否存在兼容性问题

5.3 RPC接口影响

本次变更的RPC接口的影响，需要梳理本次变更的接口的上下游调用关系，接口兼容问题。

5.4 HTTP接口影响

本次变更的HTTP接口的影响，需要梳理本次变更的接口的上下游调用关系，接口兼容问题。

6. 业务功能分析

6.1 业务实现分析

从系统用例（系统接口）维度来分析实现逻辑。

6.2 数据模型分析

数据库表结构的设计情况，主要是数据字典和数据E-R模型的展现，还有是否设计到分库分表，分块分表的拆分数量和拆分键的设计说明

7. 技术风险分析

7.1 宕机风险分析

此处重点对系统稳定性进行分析，比如流量高峰、外部接口异常等情况下对业务的影响和响应措施，具体落地为系统、业务数据监控和报警相关的分析，同时还需要分析系统报警之后的应急处理方案。

7.2 资损风险分析

如果业务涉及到资金，则需要在本处分析潜在的资损风险以及监控措施，同时还需要分析收到报警之后的止血方案。

8. 测试关注点

需要描述测试过程中需要重点关注的内容，主要涉及到核心系统变更、慢SQL、资金业务、并发问题等。

9. 灰度方案

对于业务影响较大的变更，需要分析系统的功能开关和灰度方案。

10. 研发计划

10.1 成员

10.2 规划

描述项目研发过程中接口维度的交付时间节点

11. 接口文档

描述各个环境下接口的公共基础信息，包括URL，加签验签方式等，文档详细内容复制https://fshows.yuque.com/tech-ozd0u/bgaw8p/wcyk0d 链接中的模板，并外链到本章节下

12. 发布计划

描述除了常规发布流程外特殊的关注点