需求以及架构设计

需求、设计以及架构##

需求分析

需求分析原则

• 从用户的诉求出发
• 注意边界：那些需求需要做的，那些需求是不需要做的

需求分类

• 伪需求：没有调研，没有目的，没有逻辑的需求

• 强需求或者强势力方提出需求

先肯定需求然后在提出成本等问题 根据实际情景来做推演

架构设计

用户，业务，产品，技术不同层次

KISS原则

1. keep it simle and smile 大道至简
2. simle ：可扩展性和可维护性
3. smile：价值，可测试性

DRY原则

DRY是Andy Hunt 和 Dave Thomas’s 的《 The Pragmatic Programmer
》书中的核心原则,特指在程序设计以及计算中避免重复代码，因为这样会降低灵活性、简洁性，并且可能导致代码之间的矛盾.

七大设计原则
类图设计
接口设计
组合设计

• 单一职责

每个类只完成一种业务，命名设计
例如：邮件和短信发送类都写在一个类

• 里氏代换

子类可以扩展父类的功能，但不能改变父类原有的功能，根据实际业务类处理子类和父类关系

• 接口隔离原则

接口粒度尽量小，每个接口的方法内聚一切特征
例如：鸟类的接口，具备飞行，饮食等方法接口；

• 组合复用

组合关系松散，接口是强关联
注入@Auwriter 是组合复用方式，避免接口污染

• 依赖倒置原则

高层是抽象，细节依赖抽象，底层依赖高层

• 迪米特原则

互相了解的信息，尽量少
例如：接口只关注 输入和 输出，不关注具体的代码内容

• 开闭原则

对扩展开放，对修改封闭
例如：代码可以继续扩展，任何变化都需要隔离处理，避免影响

• 熵增定律

不可逆的的事情只会越来越糟糕
开放性设计，需求的多变和业务不断试错

架构

架构能力

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

架构目的

• 确定系统边界
• 各模块之间的关联关系
• 后续系统的在既定的框架上演进
• 明确非功能需求：安全，可用，扩展

架构图

• 画好架构图

架构的类型 架构中关键要素（技术，服务）
关键要素之间的关联：包含，支撑 画出架构图

• 架构图的标准 布局：

• 位置，图形上下关系
• 颜色：分类，视觉中心，侧重点
• 逻辑：关联，组件依赖关系

• 架构图分类

业务：市场
应用：运营
数据：运维
技术：技术

• 传统架构图

物理视图
逻辑视图
开发视图：开发期质量
处理视图：运行图质量
场景视图：需求分析技术，从业务出发来绘制

• UML ：用图形描述软件模型中各个元素之间的关系

类关系
泛化（继承）、实现（实现接口）、聚合（整体和部分可以分开）、组合（整体和部分不可以分开）、依赖（类中用到对方）、关联(依赖一种特例)

类图
描述类的基础字段信息 和 读写功能 以及 每种类之间的关系