简介
T31训练营是以购票系统为背景,通过这个让我们了解整个系统从0-1的过程,抽象业务,了解系统设计的方法论,增强代码规范,增强自身解决问题的能力和团队协作能力。
感想
今天孤尽从架构的维度,给我们完整的讲述了,整个系统设计的过程。系统设计根本是更好的解决问题,不应该过于追求技术,应该从实际问题出发,以解决问题为根本,所有的技术只是为了更好的解决问题。影响最深的一句话就是,架构是一种能力,不是一个职位。任何的需求和设计都包含了架构的部分思想,对需求的看待应该从更高的维度去看,将有助于以后的扩展。
笔记
kiss原则
keep it simple and smile,架构的理念是大道至简,解决问题。
- 如何让系统有可扩展性和可维护性
- 如何让系统恰到好处的解决问题
- 如何让系统能够在运行3-5年内不需要重构
七大设计原则
1. 单一原则
模块的名字非常重要;
属性和行为想着模块预先定义的功能内聚;
高内聚、低耦合的延伸;
2. 里式代换原则
父类能出现的地方,子类一定能够出现。子类出现的地方,父类去代替,一般都有问题
3. 接口隔离原则
接口的颗粒度尽量小,一个接口的方法强内聚于同一特征
4. 组合复用原则
组合产生的对象,方法暴露的少,尽可能的只暴露与本类相关的行为。
5. 依赖倒置原则
细节依赖抽象,底层依赖于高层。
6. 迪米特原则
互相了解的信息,尽可能的少。关注一个接口,只关注输入输出。
7. 开闭原则
对扩展开放,对修改关闭。熵增定律,开闭原则是熵减。
什么是架构
架构师一种能力,不是一个职位。
架构 = 组成 + 决策
组成 = 模块结构 +模块关系
决策 = 约束 + 设计原则 + 演变方向
如何画架构图
- 搞清楚要画的架构图类型
- 确认架构图中的关键要素(产品、技术、服务)
- 梳理关键要素之间的关系
- 输出关联关系清晰的架构图
架构图的好坏
- 图形的上下左右前后6个方向的位置关系
- 视觉中心在哪里,通过颜色标记到出视觉中心,哪些是需要被忽略的。
- 3业务实现的可行性
类的六大关系
- 泛化关系:继承关系
- 实现关系:实现接口
- 聚合关系:业务上整体和部分可以分开
- 组合关系:业务上整体和部分不可以凯纷
- 依赖关系:只要在类中用到对方,就是依赖关系
- 关联关系:体现的是业务逻辑的关系,是依赖关系的特例