小系统或单个模块的设计文档

一、「一句话描述」的标题

文件名或标题最好使用「一句话描述」，如：
观测云新 Event 数据结构及处理逻辑设计
观测云云关联处理逻辑设计

二、业务流程

对业务流程进行描述，具体写明「用户做了什么操作，系统进行了什么处理，最后发生了什么」。

一般是流程图加上列表描述的方式

三、数据定义

业务流程中产生的业务实体，必须明确所有的字段、字段类型、取值范围、数据来源等信息。

注意：表格中说明不宜过长，对于某些需要复杂说明的字段，应当为其单独开设下级标题进行详细描述
对 JSON 数据，可以直接使用 JSON 格式展现，如：

{
    // [必须] 课程编号，全局唯一
    "code": "CLASS-001",
    // [必须] 课程名称
    "name": "语文 1",
    // [必须] 课程类型，可选值：文科=`liberal`、理科=`science`
	...
}

更复杂的设计文档

需要增加更多内容来说明

一、拆分大型系统的设计文档
将文档划分为层级：
1、基本设计：描述系统整体架构，不涉及具体功能内部的细节
2、详细设计：描述具体功能模块、具体功能所涉及的业务实体、处理流程、字段定义等

二、概念解释
文档中出现的的概念、业务实体需要明确的定义，避免误解。如：

• 课程class：指的是包含课件、教材的「课程内容」，如：「云计算入门」
• 场次activity：指的是某一个课程在特定时间地点进行的活动，如：「云计算入门 2021 年上海第一场」

并配合示例示例进行说明。如：

• 后台管理员创建并录入「云计算入门」课程（这里操作的是「课程class」）
• 讲师根据排课表，选择「云计算入门」开课，并指定开课时间（这里操作的是「场次activity」）
• 学生根据已经开设的课程，选择城市和时间进行报名（这里操作的是「场次activity」）
• 优于疫情，取消了 2020 年所有的培训（这里操作的是「场次activity」）
• 云计算已经深入人心，没有继续开课的必要，「云计算入门」下架（这里操作的是「课程class」）

三、架构图
无论是系统整体设计，还是单个功能模块的设计，都可以附带架构图方便读者理解。

DataFlux Func 中「订阅器」的架构图

四、项目文件目录
已经成型的项目，添加项目文件目录进行说明：

• 一方面为了让新人能够快速掌握项目整体情况；
• 另一方面为了规范后续开发工作；

DataFlux Func 项目目录说明

后面再补上参考链接