1、概述
今天2021-10-26，开始第一堂Java的架构设计课程，课程的主要内容为：
- 需求的理解
- 什么是架构
- 什么是设计原则
- 架构图
希望到课程结束时，能有一个长足的进步。
2、需求理解
2.1 理解
需求的根源是用户的需要，也是人性的本源需求。
而需求分析是，是把客户的诉求，转化为结构化、系统化、文档化的信息，从而具象化的给用户展示并提出修改意见，同时指导后续的设计和开发。
需求分析的初衷是解决用户的问题。
需求路径：需求分析->可行性->设计->编码->测试->发布
2.2 需求类型
-
伪需求，如何处理： 1、通过数据证明 2、用论证的方式，说明需求需要改进 3、使用需求推演，说明需求的不合理
-
权力需求，如何处理： 1、肯定需求，再提出需求实现的成本 2、给出更好的替代方案 3、用户数据和案例，说明该需求的不可行性
-
上述是一般程序员在工作一段时间后，能够感受到的。
-
如果你在的公司，存在能够把《伪需求》和《权力需求》通过上述手段拒绝掉的，那么请珍惜，因为大多数的公司，只能是试错。
3、什么是架构
3.1 理解
是一种能力，能力是用来解决问题的。所以架构的目的是让项目、系统的开发变得边界明确、有序、简单、结果的可预测等。
架构需要考虑非功能性需求：安全性、可用性、可扩展性等。
架构的展现是架构图，理解为：水平面上的业务模块 + 垂直面上的技术模块互相依赖，形成的逻辑结构图。
那么如何才能架构？需要学习前人的知识和经验，前人通过碰到的问题，提炼了很多的设计原则。
4、设计原则
- 单一职责
- 一个模块就干一件事
- 模块名字非常重要(你在工作中遇到有歧义、反义、汉语拼音之类的模块名，想打人吗？)
- 里氏代换原则
- 概念：更具体的一定能代替更抽象的；更抽象的一定不能代替更具体的
- 违反里氏代换原则时，可以考虑组合
- 接口隔离原则
- 概念：interface力度尽可能小
- 理念：高内聚，低耦合
- 组合复用原则：
- 与继承相比：比继承更松散、产生更少的对象、暴露的方法更少
- 正例：service注入
- 反例：implement N多interface
- 依赖倒置原则
- 细节依赖抽象，底层依赖高层
- 加深记忆：做事也是如此—先有框架再有细节
- 迪米特原则(知识最少原则)
- 只关注暴露的接口，不关注具体实现
- 加深记忆：只关注结果，不关注过程
- 开闭原则
- 概念：对扩展开发、对修改关闭
- 最熟悉的陌生原则，知易行难
- 架构师的价值：识别和隔离变化点(不要相信产品，不要相信任何人)
- 开闭原则是熵减，好程序员一般都有熵减的怪癖
总结： 上面的设计原则，从理解上来讲：
- 要求职责单一，如：单一职责 、接口隔离原则、迪米特原则等，其实都是说要简单、要做属于自己的事情。
- 要求代码复用，如：组合复用原则、单一职责 、接口隔离原则、迪米特原则等
- 要求易维护、易扩展，如：开闭原则 、依赖倒置原则等
再仔细想下，上述三者又是相辅相成的，单一了肯定复用、也容易维护等。
5、架构图
- 要容易度
- 布局： 框框的上、下、左、右、前、后，6个方向的位置关系
- 颜色：突出重点
- 逻辑：逻辑清晰
- 架构的分类（没达到这个高度，没啥理解可以说）
- 纯业务架构
- 应用架构
- 数据架构
- 技术架构：去掉水平层面的业务模块，纯技术上的垂直依赖、例如从低向上的分层为：数据库——DAO——service——Web——用户。
- 架构图分类（4+1）
- 物理视图(一般不画)
- 逻辑视图(逻辑结构图)
- 开发视图 (UML)
- 处理视图 (UML)
- 场景视图 (UML)
- 架构图分类（4+1）
- 类的六大关系：泛化(继承)、实现、聚合(空心菱形)、组合(黑色菱形，耦合性比聚合更强)、依赖、关联
记住了聚合和组合
