T31训练营-DAY1

简介

T31训练营是以购票系统为背景，通过这个让我们了解整个系统从0-1的过程，抽象业务，了解系统设计的方法论，增强代码规范，增强自身解决问题的能力和团队协作能力。

感想

今天孤尽从架构的维度，给我们完整的讲述了，整个系统设计的过程。系统设计根本是更好的解决问题，不应该过于追求技术，应该从实际问题出发，以解决问题为根本，所有的技术只是为了更好的解决问题。影响最深的一句话就是，架构是一种能力，不是一个职位。任何的需求和设计都包含了架构的部分思想，对需求的看待应该从更高的维度去看，将有助于以后的扩展。

笔记

kiss原则

keep it simple and smile，架构的理念是大道至简，解决问题。

• 如何让系统有可扩展性和可维护性 
• 如何让系统恰到好处的解决问题
• 如何让系统能够在运行3-5年内不需要重构

七大设计原则

        1. 单一原则

模块的名字非常重要；

属性和行为想着模块预先定义的功能内聚；

高内聚、低耦合的延伸；

        2. 里式代换原则

父类能出现的地方，子类一定能够出现。子类出现的地方，父类去代替，一般都有问题

        3. 接口隔离原则

接口的颗粒度尽量小，一个接口的方法强内聚于同一特征

        4. 组合复用原则

组合产生的对象，方法暴露的少，尽可能的只暴露与本类相关的行为。

        5. 依赖倒置原则

细节依赖抽象，底层依赖于高层。

        6. 迪米特原则

互相了解的信息，尽可能的少。关注一个接口，只关注输入输出。

        7. 开闭原则

对扩展开放，对修改关闭。熵增定律，开闭原则是熵减。

什么是架构

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

架构 = 组成 + 决策

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

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

如何画架构图

1. 搞清楚要画的架构图类型
2. 确认架构图中的关键要素(产品、技术、服务)
3. 梳理关键要素之间的关系
4. 输出关联关系清晰的架构图

架构图的好坏

1. 图形的上下左右前后6个方向的位置关系
2. 视觉中心在哪里，通过颜色标记到出视觉中心，哪些是需要被忽略的。
3. 3业务实现的可行性

类的六大关系

• 泛化关系：继承关系
• 实现关系：实现接口
• 聚合关系：业务上整体和部分可以分开
• 组合关系：业务上整体和部分不可以凯纷
• 依赖关系：只要在类中用到对方，就是依赖关系
• 关联关系：体现的是业务逻辑的关系，是依赖关系的特例