【架构设计】概要设计评审
概要设计评审
1. 系统功能范围：
1.1 整理需求用例（新平台或多系统需求）
- 从产品提供的需求文档中提取用例。
- 确定系统的边界（什么事情做，什么事情不做）。
- 为识别领域对象提供简洁和完整的支持。
| 要求 | 描述 |
|---|---|
| 完整性 | 概要设计应该覆盖详细需求设计 |
| 识别系统干系人 | 找到产品需求功能的用户，可能是人、软件 |
| 识别需求的关系 | 需求之间的泛化、包含、扩展，以便于模块的划分 |
用例图示例：
用例图教程：https://kb.cnblogs.com/page/129491/
1.2 模块划分
| 要求 | 描述 |
|---|---|
| 覆盖当前所有需求 | 详细需求设计上的任一需求都能在某模块中找到 |
| 模块内聚性 | 模块包含的需求共同完成一个领域功能，模块可以单独开发和测试 |
| 模块低耦合 | 模块间只能通过API建立链接，除此链接，模块间不需要知道彼此的实现细节 |
依赖关系：使用系统模块图描述模块间关系
| 要求 | 描述 |
|---|---|
| 单向依赖 | 系统或模块之间不能双向关联，避免耦合 |
模块图示例
协作关系：使用时序图描述模块间协作关系
| 要求 | 描述 |
|---|---|
| 图示协作关系 | 用uml的协作图描述协作关系，展示时序和输入输出 |
系统协作图示例
1.3 API设计
| 要求 | 描述 |
|---|---|
| 输入输出描述 | 使用rap描述接口详细功能，代码中使用多行注释 |
| 单一输入 | 不强制用类进行封装，建议使用类，方便扩展 |
| 单一输出 | 不强制用类进行封装，建议使用类，方便扩展 |
| 多参输出 | 建议用类进行封装 |
| 多参输出 | 建议用类进行封装 |
| 界定合法输入 | 告知调用者什么样的输入才合法，比如id不能为空、手机号长度11位 |
| 承诺输出结果 | 告知调用者合法的情况下返回结果一定是什么 |
| 异常情况 | 区分系统异常和业务异常 |
| 不删除旧接口 | 如果不确定接口已不使用，不能删除旧接口，可使用@Deprecated |
| 不修改旧接口 | 如果不确定旧接口被谁使用，则不能修改旧接口 |
| 新增优于修改 | 如果修改接口影响较大，建议直接新增接口，做好接口版本管理 |
备注：此处API设计为概要
1.4 数据库设计
| 要求 | 描述 |
|---|---|
| 分清数据库 | 确定需要涉及哪些数据库变更 |
| 表设计 | 使用PowerDesign描述：表名、字段名、主键、是否为空，外键、值约束、默认值，如果有数据冗余处理，需要说明原因和存取规则 |
| 表关系 | 使用ER图描述实体与实体之间的关系 |
数据库ER图示例：
ER图教程：powerdesigner 画ER图
1.5 适配既有系统架构
| 要求 | 描述 |
|---|---|
| 适配既有硬件拓扑结构 | 尽量沿用，如果不能满足，提出方案进行评审 |
| 适配既有软件部署位置 | 尽量沿用，如果不能满足，提出方案进行评审 |
| 适配既有系统环境 | 尽量沿用，如果不能满足，提出方案进行评审 |
| 适配既有数据库 | 尽量沿用，如果不能满足，提出方案进行评审 |
| 适配既有基础架构 | 尽量沿用，如果不能满足，提出方案进行评审 |
2. 技术框架选型:
| 名称 | 描述 |
|---|---|
| JDK | jdk1.7，特殊情况下需要使用jdk1.7以上版本，需要经过架构组确认 |
| RPC框架 | dubbo |
| 缓存 | redis |
| 消息队列 | rocket mq |
| 关系型数据库 | mysql 主备 |
| 配置中心 | disconf |
| 监控平台 | cat |
| 日志平台 | elasticSearch+filebeat+kibana |
| 应用容器 | tomcat 7、8 |
| 定时任务 | elastic-job |
| 负载均衡 | tengine |
| 规则引擎 | drools |
| 文件系统 | oss |
| 协调服务 | zookeeper |
| 非关系型数据库 | mongodb |
详见：架构规范
