系统设计方案论

项目落地过程： 需求分析->可行性->设计->编码->测试->发布

kiss原则： keep it simple and smile(大道至简，迎接否定)

DRY： Don’t repeat yourself.

需求分析

• 用户诉求（调研）
• 背后逻辑（人性是需求的本源）
• 可行性结果分析

 1.数据化结果判断合理性
 2.正反案例说明需求需改进的地方
 3.用户路径和触点推演合理性及危害性

非结构——结构
需求产品化： 模块化、 配置化、 有逻辑

架构

1.什么是架构？

组成+决策

组成：模块关系+模块结构
决策：约束+设计原则+演化方向

2.为什么架构？

解决问题
技术层面上确定模块结构，梳理各模块之间的依赖关系与模块的宏观输入与输出，使后续的子系统或模块设计在一个既定的技术约束上继续演化

1.可扩展和维护
2.使用合理的解决问题方式
3.尽量不重构

3.如何架构？

3.1架构分类

3.1.1业务架构

使用方法论，对涉及到的业务单元进行边界划分

3.1.2.应用架构

对系统进行垂直应用层次拆分

3.1.3.数据架构

对存储数据的逻辑，根据各个系统，不同时间段应用场景，数据读写分离，异构，缓存，分布式等策略进行划分。

分析：
数据源
存储方式
如何架构设计

3.1.4技术架构

根据需求，进行技术选型，并描述清楚之间的关系。

3.2 架构图

3.2.1 介绍

 水平的业务单元+垂直技术单元 构成的逻辑结构图

3.2.2 作用

可视化 提高效率

3.2.3 常用

逻辑视图： 功能需求架构（逻辑结构图）
开发视图： 开发期质量属性的架构（UML图）
处理视图： 运行期质量属性的架构（UML图）

3.2.4 UML类图

常用：类图，时序图，流程图

静态结构图：类图、对象图、包图、组件图、部署图
动态行为图：交互图（时序图与协作图）、状态图、活动图

3.2.5 类之间的关系

泛化关系：继承
实现关系：实现接口
聚合关系：业务与整体 独立存在
组合关系：业务与整体 同生共死
依赖关系：只要在类中用到了对方，就存在依赖关系
关联关系：体现的是业务逻辑的关系，是依赖关系的特例

3.2.6 七大设计原则

单一职责： 不忘初心（高内聚，低耦合）

里氏替换： 父有子必有

接口隔离原则： 接口尽可能小（退款：用户侧，管理侧）

组合： 恋爱关系（尽可能使代码暴露与本类相关的代码，避免接口污染）

依赖倒置原则：细节依赖于抽象，底层依赖于高层

迪米特原则：互相了解的信息尽可能少，只关注输入和输出

开闭原则：对扩展开放（变化的点隔离出来）。

3.2.7 分层

**多视角：**用户/业务/产品/技术

3.2.8 如何画？

1.分析类型（业务，应用，数据，技术）
2.确定要素（产品，技术，服务）
3.关联（包含，并列）
4.输出关联关系

【注意】：布局，颜色，逻辑（突出重点！）