# 架构
《架构整洁之道》读书笔记
# 编程范式
- 结构化编程，结构化编程对程序控制权的直接转移进行了限制和规范。限制goto语句
- 面向对象编程，面向对象编程对程序控制权的间接转移进行了限制和规范。限制函数指针
- 函数式编程，函数式编程对程序中的赋值进行了限制和规范。限制赋值语句的使用
# 软件架构
- 功能性
- 组件独立性
- 数据管理
- 顺序结构
- 分支结构
- 循环结构
# 面向对象
- 封装
- 继承
- 多态
# 设计原则
SOLID原则
- SRP: 单一职责原则。每个软件模块有且只有一个需要被改变的理由
- OCP: 开闭原则。如果软件系统想要更容易被改变，其设计必须允许新增代码来修改系统行为，而非只能靠修改原来的代码
- LSP: 里氏替换原则。软件系统的组件要遵守同一个约定，以便让这些组件可以相互替换
- ISP: 接口隔离原则。在设计中避免不必要的依赖
- DIP: 依赖反转原则。高层策略性代码不应该依赖实现底层细节的代码，实现底层细节的代码应该依赖高层策略性代码
- LKP: 最少知识原则。一个软件实体应当尽可能少地与其他实体发生相互作用
# 架构关注点
架构是系统设计的一部分，它突出了某些细节，并通过抽象省略掉另一些细节。
架构关注的是组件之间的关系和系统组件外部可见的属性，设计还要关注这些组件的内部结构。
# 架构关注点
- 品质关注点，例如稳定性，技术栈等
# 组件构建基本原则
- REP：复用/发布等同原则。软件复用的最小粒度应等同于其发布的最小粒度
- CCP：共同闭包原则。将会同时修改，且为了相同目的而修改的代码放到同一个组件中。反之亦然。
- CRP：共同复用原则。不应强迫一个组件的用户依赖他们不需要的东西。
# 什么是软件架构
设计软件架构的目的是为了在工作中更好地对这些组件进行研发、部署、运行以及维护。
软件架构设计的主要目标是支撑软件系统的全生命周期，设计良好的架构可以让系统便于理解、易于修改、方便维护，并且能轻松部署。软件架构的终极目标就是最大化程序员的生产力，同时最小化系统的总运营成本。
对于一个只有五个开发人员的小团队来说，他们完全可以非常高效地共同开发一个没有明确定义组件和接口的单体系统（monolithic system）。
设计良好的系统架构应该可以使开发人员对系统的运行过程一目了然。
所有的软件系统都可以降解为策略与细节这两种主要元素。策略体现的是软件中所有的业务规则与操作过程。
软件架构师的目标是创建一种系统形态，该形态会以策略为最基本的元素，并让细节与策略脱离关系，以允许在具体决策过程中推迟或延迟与细节相关的内容。
软件架构设计本身就是一门划分边界的艺术。边界的作用是将软件分割成各种元素，以便约束边界两侧之间的依赖关系。
本质上，所有的软件系统都是一组策略语句的集合。
软件架构设计的工作重点之一就是，将这些策略彼此分离，然后将它们按照变更的方式软件架构设计的工作重点之一就是，将这些策略彼此分离，然后将它们按照变更的方式进行重新分组。其中变更原因、时间和层次相同的策略应该被分到同一个组件中。反之，变更原因、时间和层次不同的策略则应该分属于不同的组件。
我们对“层次”是严格按照“输入与输出之间的距离”来定义的。一条策略距离系统的输入/输出越远，它所属的层次就越高。而直接管理输入/输出的策略在系统中的层次是最低的。
我们希望源码中的依赖关系与其数据流向脱钩，而与组件所在的层次挂钩。
离输入/输出最远的策略——高层策略——一般变更没有那么频繁。即使发生变更，其原因也比低层策略所在的组件更重大。反之，低层策略则很有可能会频繁地进行一些小变更。
# 业务逻辑
如果我们要将自己的应用程序划分为业务逻辑和插件两部分，就必须更仔细地了解业务逻辑究竟是什么，它到底有几种类型。
业务逻辑就是程序中那些真正用于赚钱或省钱的业务逻辑与过程。更严格地讲，无论这些业务逻辑是在计算机上实现的，还是人工执行的，它们在省钱/赚钱上的作用都是一样的。
“关键业务逻辑”通常会需要处理一些数据，我们将这些数据称为“关键业务数据”，关键业务逻辑和关键业务数据是紧密相关的，所以它们很适合被放在同一个对象中处理。我们将这种对象称为“业务实体（Entity）”。
# 架构设计的主题
架构设计不是（或者说不应该是）与框架相关的，框架只是一个可用的工具和手段。
软件的系统架构应该为该系统的用例提供支持。