【架构设计】概要设计评审

概要设计评审

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

详见：架构规范