T31训练营-架构设计

Day1:

一.需求分析

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

二.KISS原则:keep it simple and smile

三.DRY原则:Don't repeat yourself

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

    重复代码的危害性：不一致性，代码冗余，易出bug

四.七大设计原则

共同点：提升软件的可扩展性，可维护性

实践点：类图设计 接口设计 组合设计

• 单一职责原则

最简单的,却是最难的，高内聚、低耦合的延申

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

• 里氏替换原则

父类出现的地方，子类一定能够出现，这是里氏替换，而子类出现的地方，用父类去替代，一般都有问题

如 鱼能游，鲨鱼能游，可以。

反之 鲨鱼有牙齿，推导不出 鱼有牙齿

车能开，跑车能开，可以。

反之 跑车的推背感很强，推到不出 车的推背感很强

• 接口隔离原则

接口的粒度尽可能地小

同一接口的方法强内聚于同一特征

• 组合复用原则

继承是一种绑定关系，相当于父子关系

组合是一种松散的合作关系，相当于谈恋爱

组合产生的对象，方法暴漏的少

继承产生的的对象，继承路线上的方法全部暴漏出来

增加用户的选择成本，容易误用

• 依赖倒置原则

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

宪法不可能依赖于地方法律

网络服务只依赖于协议，而不是具体硬件

• 迪米特原则

互相了解的信息，尽可能的少

你使用一个接口，你只关注：输入和输出，不需要关注具体代码实现

• 开闭原则

对扩展开发，对修改关闭

扩展能力主要是对需求继续变化的适应能力

五.架构

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

架构=组成+决策

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

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

架构的目的：

确定系统边界，在技术层面上做与不做

确定系统里各模块之间的依赖关系与模块的宏观输入与输出

架构图：

1.搞清要画的架构图的类型

2.确认架构图中的关键要素(产品、技术、服务)

3.梳理关键要素之间的关联:包含、支撑、同级并列

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

布局 颜色 逻辑

类的六大关系：

泛化关系：继承关系

实现关系：实现接口

聚合关系：业务上整体与部分可以分开，是关联关系的特例

组合关系：业务上整体与部分不可以分开，同样是关联关系的特例

依赖关系：只要在类中用到l对方，就存在依赖关系

关联关系：体现的是业务逻辑的关系，是依赖关系的特例，具有导航性&多重性

 

架构分类：

        业务架构

        应用架构

        数据架构

        技术架构

时序图：关注正常流程，不关注逆流程，不关注异常流程，不关注分支判断