上课时间：2021-10-26 20:00-22:00
老师从介绍训练营的主要项目《T31项目》（一个类似于12306的售票网站）开始，引出项目开始时需要做的两件事情：
- 需求分析
- 架构设计
一、需求分析
需求分析的定义
需求分析过程中遇到的问题以及应对方法
以及《T31项目》需求分析的内容
项目在全生命周期中的问题分层
解决上述问题需要坚持的原则，老师自创的KISS原则 Keep it simpe and smile
和开发过程中的 DRY原则 Don’t Repeat yourself
二、架构设计
在进行架构设计前应该理解的七大架构设计原则
1.单一职责原则
- 最简单的，但是却是最难的！
- 高内聚、低耦合的延伸
- 属性和行为向着模块预先定义的功能内聚
- 模块的名字非常重要
2.里氏代换原则
- 父类能够出现的地方，子类一定能够出现，这是里氏代换
- 而子类出现的地方，用父类去代替，一般都有问题
3.接口隔离原则
- 接口的粒度尽可能地小同一接口的方法强内聚于同一特征
- 比如飞机的接口Fly，它有land(), takeoff() 如果加入引擎的start()方法 必须定义另一个接口Engine
4.组合复用原则
- 继承是一种绑定关系，相当于父子关系
- 组合适一种松散的合作关系，相当于谈恋爱
- 组合产生的对象，方法暴露的少
- 继承产生的对象，继承路线上的方法全部暴露出来
- 增加用户的选择成本，容易误用
5.依赖倒置原则
- 细节依赖抽象
- 底层依赖于高层
- 宪法不可能依赖于地方法律
- 我们的网络服务只依赖于协议，而不是具体的硬件
6.迪米特原则
- 相互了解的东西，尽可能的少
- 你使用一个接口，你只关注：
- 输入和输出，不需要关注具体代码实现 我们听歌时，我们也不需要关注内部芯片的处理，我们只关注接口是圆的，还是蓝牙的
7.开闭原则
- 对扩展开放 对修改关闭 扩展能力主要是对需求继续变化的适应能力 代码最大的稳定性，一旦成功运行，就不应该该具体的代码扩展 通过依赖倒置，实现增加类，或模块的方式，实现需求的变化 任何变化的点，都是需要被隔离出来的 架构师最大的难点：识别和隔离变化点
在设计时应该记得熵增定律
熵：反应自发过程的不可逆性的物质状态指标，这是衡量我们这个世界中事物混乱程度的一个重要指标。 一个孤立系统总是存在从 有序度转变成无序的趋势，这就是熵增定律。熵增是我们宇宙 最绝望的定律，我们有办法抑制混乱程度的加剧吗？
架构的定义
- 架构是一种能力，不是一个职位
- 架构 = 组成 + 决策
- 组成 = 模块结构 + 模块关系
- 决策 = 约束 + 设计原则 + 演化方向
架构的目的
- 确定系统边界，在技术层面上做与不做
- 确定系统里各模块之间的依赖关系与模块的宏观输入与输出
- 使后续的子系统或模块设计在一个既定的框架内和技术方向上继续演化 明确非功能性需求，非功能性需求是指安全性、可用性、可扩展性等
如何画架构图
- 搞清楚要画的架构图的类型
- 确认架构图中的关键要素（比如产品、技术、 服务）
- 梳理关键要素之间的关联：包含、支撑、同级并列等
- 输出关联关系清晰的架构图
架构图质量好坏的评估维度
- 布局
- 图形的上下左右 前后6个方向的位置关系
- 颜色
- 视觉中心在哪里
- 哪些元素被忽略
- 逻辑
-
组件之间的依赖
-
业务实现的可行性
-
《T31项目》的架构设计实例：
架构图的分类
-
业务架构
- 使用一套方法论，对所涉及到的业务单元进行边界划分 熟悉业务
- 比如：团购网站系统->商品类目，订单服务，支付，退 款等进行清晰划分
-
应用架构
- 对整个系统的实现进行可视化落地实践，系统的层次/开 发原则/各个层次的应用服务，一般为垂直依赖型。
- 比如：团购网站系统->数据层，服务层，通讯层，展现
-
数据架构
- 是一套对存储数据的架构逻辑，根据各个系统应用场景、 不同时间段的应用场景 ，对数据进行诸如数据异构、读写 分离、缓存使用、分布式数据策略等划分。
- 思考：系统需要什么样的数据？如何存储这些数据？如何 进行数据架构设计？
-
技术架构
- 承接应用架构的技术需求，并根据识别的技术需 求，进行技术选型，把各个关键技术和技术之间 的关系描述清楚。
传统架构图 4 + 1
- 物理视图： 和部署相关的架构决策（一般不画）
- 逻辑视图： 设计满足功能需求的架构（逻辑结构图）
- 开发视图： 设计满足开发期质量属性的架构（UML图）
- 处理视图： 设计满足运行期质量属性的架构（UML图）
- 场景视图： 需求分析技术，通常采用UML的用例图进行设计
UML定义
Unified Model Language: 统一建模语言 使用图形和符号描述软件模型中的各个元素 和他们之间的关系
- Unified： 说明以前不统一
- Model： 建模往往需要抽象
- Language： 交流，为啥能够交流，定义共同的协议！
UML分类
- 静态结构图：类图、对象图、包图、组件图、部署图
- 动态行为图：交互图（时序图与协作图）、状态图、活动图
类的六大关系
- 泛化关系：即继承关系
- 实现关系：实现接口
- 聚合关系：业务上整体与部分可以分开，是关联关系的特例
- 组合关系：业务上整体与部分不可以分开，同样是是关联关系的特例
- 依赖关系：只要在类中用到了对方，就存在依赖关系
- 关联关系：体现的是业务逻辑的关系，是依赖关系的特例，具有导航性&多重性
时序图
架构图的作用是什么？
- 将目标系统的结构可视化，通过直观的方式描述技术思维减少沟通障碍，提升协作效率划分目标系统的边界。
