T31项目Day01架构设计

一、需求分析

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

1.需求边界

需求细化到什么程度就停止。

2.用户故事

即需求产生的场景。

3.用户路径

用户路径越短越好。

二、七大设计原则

1.单一职责原则（SRP：Single responsibility principle）

高内聚、低耦合

2.里氏替换原则（LSP：Liskov Substitution Principle）

在任何父类出现的地方都可以用他的子类来替代（反之在子类出现到的地方用父类替代往往是错的）

3.接口隔离原则(ISP：Interface Segregation Principle)

接口的粒度尽可能地小同一接口的方法强内聚于同一特征。

4.组合复用原则（CRP：Composite Reuse Principle）

尽量使用对象组合，而不是继承来达到复用的目的。

该原则就是在一个新的对象里面使用一些已有的对象。

因为继承在调用的时候会把继承路线上所有的方法都暴露出来，增加用户的选择成本。

5.依赖倒置原则（DIP：Dependence Inversion Principle）

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

6.迪米特原则（LOD：Law of Demeter）

互相了解的信息，尽可能的少。使用接口，只需要关心输入和输出，不需要关心具体实现。

7.开闭原则（OCP：Open Closed Principle）

对扩展开放，对修改关闭。即在设计一个模块的时候，应当使这个模块可以在不被修改的前提下被扩展。

什么是架构？

架构=组成+决策

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

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

三、架构图设计

1.架构图的好坏

①布局

位置关系一般情况下，上面的模块依赖下面的模块，叠加在一起的图层一般认为上图层依赖于下图层。

②颜色

视觉中心应置为扎眼的颜色，依赖中间件等可设置为灰色等不显眼的颜色。

③逻辑

组件之间的依赖业务实现的可行性。

2.架构图分类

①业务架构

使用一套方法论，对所涉及到的业务单元进行边界划分。

②应用架构

对整个系统的实现进行可视化落地实践，系统的层次 / 开发原则/ 各个层次的应用服务，一般为垂直依赖型。

③数据架构

是一套对存储数据的架构逻辑，根据各个系统应用场景、不同时间段的应用场景 ，对数据进行如数据异构、读写分离、缓存使用、分布式数据策略等划分。

④技术架构

承接应用架构的技术需求，并根据识别的技术需求，进行技术选型，把各个关键技术和技术之间 的关系描述清楚。

3.UML图

分类：

静态结构图：类图、对象图、包图、组件图、部署图

动态行为图：交互图（时序图与协作图）、状态图、活动图

4.类的六大关系：

①泛化关系：即继承关系

②实现关系：实现接口

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

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

⑤依赖关系：只要在类中用到了对方，就存在依赖关系。如果没有对方，连编译都通过不了。

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

心得体会：很庆幸能在开发生涯比较早的阶段就接触到这方面的知识，之前一直都以为架构就是专属于架构师的工作，开发就老老实实做业务需求就完事了，可当自己真正学习到这方面的知识，发现架构能力也是可以从早期就开始培养的，架构就如同生活中的的计划一样，架构做好了，事半功倍，一个好的架构设计能时刻提醒自己现在做的这个模块未来可能会在什么地方进行扩展，让我们不至于在敲代码的过程中还要额外的花精力思考这些问题，或者是直接忽视这个问题，可以帮助我们理解一些难以理解的需求，或许你单独做某个功能你觉得毫无意义，可放到架构中他也可能是一个比较重要的前置依赖项，我们不必再为了纠结这个功能到底做还是不做，因为要做的理由都明明白白的写在了架构图上，不需要做的功能也早在架构设计阶段剔除掉了，不用等到开发完这个功能之后才回过神发现这个功能好像没有意义。