T31训练营笔记（1）架构设计

1. 需求分析

1.1 定义

理解和挖掘用户的诉求、以及背后的逻辑，转化成可行性的分析结果。从非结构化到结构化，确定系统的职责、模块的过程。

1.2 需求的三个注意点

边界、用户故事、用户路径

分析需求背后的人性：人性是提出需求的本源

1.3 伪需求、权力需求的应对

1.3.1 伪需求应对

（1）用数据化结果否定需求合理性
（2）用正反案例来说明需求需要改进的地方
（3）用户路径和触点推演需求合理性

1.3.2 权力需求应对

（1）先肯定需求价值再提出需求实现的成本
（2）给出更好的需求替代方案
（3）从数据和案例角度说明需求快速上线危害性

1.4 问题的分层

用户问题、业务问题、产品问题、技术问题

1.5 KISS原则

Keep it simple and smile

simple: 架构的理念是大道至简：解决问题

smile：现代软件需要很强的协调能力，保持微笑，迎接各种否定

1.6 DRY原则

Don't repeat yoursef

一切重复的代码都可以抽象

重复代码危害性：不一致性、代码冗余、易出BUG

2. 七大设计原则

单一职责、里氏代换、接口隔离、组合复用、依赖倒置、迪米特、开闭

共同点：提升软件的可扩展性，可维护性是抽象思维和归纳思维的集中体现

熵增是自然定律，而开闭原则是熵减。

3. 架构与架构图

3.1 架构是什么

架构是一种能力，而不是一个职位

架构 = 组成 + 决策

组成 = 模块结构 + 模块关系

决策 = 约束 + 设计原则 + 演化方向

3.2 架构的目的

（1）确定系统边界、

（2）确定各模块之间的依赖关系与模块的宏观输入与输出

（3）明确非功能性需求（安全性、可用性、可扩展性等）

3.3 架构图是什么

架构图是表达架构的载体，是水平的业务单元+垂直的技术单元组成的逻辑结构图

3.4 架构图的作用

将目标系统的结构可视化，通过直观的方式描述技术思维，减少沟通障碍，提升协作效率，划分目标系统的边界

3.5 如何画架构图

（1）确定类型

（2）确认关键要素

（3）梳理关键要素之间的关联

（4）输出关联关系清晰的架构图

3.6 架构图的好坏

布局、颜色、逻辑

3.7 架构图的分类

业务架构、应用架构、数据架构、技术架构

3.8 传统架构图 4+1

物理视图、逻辑视图、开发视图、处理视图

场景视图：需求分析技术，通常采用UML的用例图进行设计

3.9 UML

（1）全称：Unified Model Language

（2）分类：

静态结构图：类图、对象图、包图、组件图、部署图

动态行为图：交互图（时序图与协作图）、状态图、活动图

（3）类的六大关系：泛化、实现、聚合、组合、依赖、关联

4. 23个设计模式

4.1 创建型：单例、原型、工厂方法、抽象工厂、建造者

4.2 结构型：代理、适配器、桥接、装饰、外观、享元、组合

4.3 行为型：模板方法、策略、命令、职责链、状态、观察者、中介者、迭代器、访问者、备忘录、解释器