1. 开题
今天是孤尽老师训练营的正式第一次课程。课程基于T31项目主要讲解了系统需求分析方法，架构问题的分层讨论。七大设计原则，并介绍了架构设计常用架构图的设计理念。感受到了孤尽老师很强的技术功底，对很多细节性的概念的认知都特别的精准。也纠正了自己很多错误的认识。这里抛出一些老师课程中的金句：
架构是组成和决策。架构是一种能力，而不是岗位。从进入职场的第一天起，就要培养自己的架构能力。
保持初心，紧跟用户的需求。
七大设计原则要内化于心，存在大脑缓存里，而不是大脑磁盘中。
道法术器势，起势了就不要让自己停下来，既然进入了孤尽班，就狠下心把课程学好。
2. 需求分析和问题分层
需求分析要紧跟用户的诉求，分析需求背后的人性。
需求就是把用户诉求转换成结构化的描述和产品化的实现。
针对伪需求，要反问有没有做过PMF，就是市场产品契合度调查。在非常复杂的系统里，用户路径是比较复杂的，要尽可能缩短用户路径。
3. 七大设计原则
在讲述7大设计原则前，老师还引入了2个自己的架构原则：
KISS原则：Keep it simple and Smile
架构的理念是大道至简：解决问题。
现代软件需要很强的协调能力，保持微笑，迎接各种否定。
DRY原则：Don't Repeat yourself
一切重复的代码都可以抽象
单一职责原则
类的属性和行为要向着模块预先定义的功能内聚。
里氏替换原则
放下武器（手枪自动也会放下） 里氏替换原则通俗来讲就是：子类可以扩展父类的功能，但不能改变父类原有的功能。也就是说：子类继承父类时，除添加新的方法完成新增功能外，尽量不要重写父类的方法。
接口隔离原则
接口的粒度尽可能地小，同一接口的方法强内聚于同一特征。
组合复用原则
组合产生的对象，方法暴露的少；继承产生的对象，继承路线上的方法全部暴露出来。增加用户成本，容易误用。
依赖倒置原则
细节依赖抽象，底层依赖高层；要面向接口编程。
迪米特原则
模块间相互处理的接口是不是处理的干干净净？是不是输入输出一定是完全匹配的？会不会有多出的异常抛给了对方？
开闭原则
写好的代码，尽量少做类似添加if else的修改。增加代码而不是修改原有代码。 开闭原则是熵减。
4. 架构图
架构图定义：水平面上的业务模块和垂直面上的技术模块互相依赖形成的逻辑结构图。
架构图的分类
业务架构，应用架构，数据架构，技术架构
传统架构图
物理视图，逻辑视图，开发视图，处理视图，场景视图
UML
UML架构图最主要的是类图和时序图。
类图要注意组合和聚合，组合有更为严格的耦合和不可分割的特性，对于图形中菱形应该为黑色。
为何在架构上区分组合和聚合：我们学习不是教条主义，要搞清楚背后的原因；分配任务，组合关系的多个模块尽可能交给同一个人做，减少耦合。
架构图的作用是将目标系统的结构可视化，通过直观的方式描述技术思维减少沟通障碍，提升协作效率，划分目标系统的边界。
5. 设计模式
工厂模式、单例模式、适配器模式、装饰者模式、代理模式、观察者模式、策略模式等。
尝试能用每一个设计模式输出 ‘helllo world’。
