第一部分 概述
设计（Design）与架构（Architecture）区别是什么？
一丁点区别都没有！
“架构”这个词往往使用于“高级层”的讨论中，这类讨论一般都把“底层”细节排除在外。而“设计”一词，往往用来指代具体的系统底层组织结构和实现细节。但是，从一个真实的系统架构师的日常工作来看，这样的区分是根本不成立的。
第二部分 编程范式
- 结构化编程是对程序控制权的直接转移的限制；
- 面向对象编程是对程序控制权的间接转移的限制；
- 函数式编程是对程序中赋值操作的限制；
第三部分 设计原则
SOLID设计原则
SRP（单一职责原则）：
每个软件模块都有且只有一个需要改变的理由。
适用范围：方法、类、接口、包、模块、应用(应用的职责)、系统(业务系统的边界)
OCP（开闭原则）：
核心要素是：如果软件系统想要更容易被改变，那么其设计就必须允许新增代码来修改系统行为，而非只能靠修改原来的代码
LSP（里氏替换原则）：
如果想用可替换组件来构建软件系统，那么这些组件必须遵守同一个约定，以便让这些组件可以相互替换。
软件架构层面，一旦违背了可替换性，该系统架构就不得不为此增添大量复杂的应对机制。
ISP（接口隔离原则）
主要告诫软件设计师应该在设计中避免不必要的依赖。 任何层次的软件设计如果依赖了它并不需要的东西，就会带来意料之外的麻烦
DIP（依赖反转原则）：
高层策略性的代码不应该依赖实现底层细节的代码，洽洽相反，那些实现底层细节的代码应该依赖高层策略性的代码
第四部分 组件构建原则
构建组件相关原则
REP（复用/发布等同原则）
软件复用的最小粒度应等同于其发布的最小粒度。
CCP（共同闭包原则）
我们应该将那些同时修改，并且为相同目的而修改的类放到同一个组件中，而将不会同时修改，并且不会为了相同目的而修改的哪些类放到不同的组件中。
CRP（共同复用原则）
不用强迫一个组件的用户依赖他们不需要的东西。
组件之间关系原则
ADP（无依赖环原则）
组件依赖关系图中不应该出现环
SDP（稳定依赖原则）
依赖关系必须要指向更稳定的方向
SAP（稳定抽象原则）
一个组件的抽象化程度应该与其稳定性保持一致
第五部分 软件架构
整洁架构
依赖关系规则
越靠近圆心即越是稳定的，即代表高层策略，越外围表示是低层组件,
源码中的依赖关系必须只指向同心圆的内层，即由底层机制指向高层策略
- 业务实体层：包含业务实体，即应用的业务对象，封装最通用最高层的业务逻辑(单独某个业务实体的逻辑)，它不应该受外界影响
- 用户用例层：实现用户某个用例场景的业务逻辑封装，是对业务实体的组装、封装
- 接口适配层：目的是进行数据的交换，包含有网关、控制器、展示器， 如：实体层和用户实例层使用的数据转化成为持久层能使用的数据，比如数据库
- 框架与驱动层：包含数据库、用户界面、web框架等
