1. 设计与架构
软件架构的终极目标是，用最小的人力成本来满足构建和维护该系统的需求。
一个软件架构的优劣，可以用它满足用户需求所需要的成本来衡量。如果该成本很低，且在系统的生命周期内始终很低，那么这个系统的设计就是优良的。反之，就是不好的设计。
胡乱编写代码的工作速度，其实比循规蹈矩更慢。要想跑得快，先要跑得稳。
2. 两个价值维度
- 行为价值：程序按照需求文档要求的方式工作
- 架构价值：软件的“软”，即软件的灵活性
艾森豪威尔矩阵
| 重要且紧急 | 重要不紧急 |
| 不重要但紧急 | 不重要且不紧急 |
- 紧急的事情往往没那么重要，而重要的事情似乎永远也排不上优先级。
- 第一个价值维度：系统行为，是紧急的，但是并不总是特别重要。
- 第二个价值维度：系统架构，是重要的，但是并不总是特别紧急。
- 应有的排序：
- 重要且紧急
- 重要不紧急
- 不重要但紧急
- 不重要且不紧急
- 常犯的错误：将第三优先级的事情提到第一优先级去做。导致重要的事情被忽略。
- 平衡系统架构的重要性与功能的紧急程度，是软件研发人员自己的职责。
建议：为好的软件架构而持续斗争
研发团队必须从公司长远利益出发，与其他部门抗争，公司内部的抗争本来就是无止境的。
软件的可维护性需要由你来保护，这是你的职责，公司雇你的很大一部分原因就是需要有人来做这件事。
3. 编程范式
编程范式指的是程序的编写模式。一共只有三种编程范式，而且未来几乎不可能再出现新的。
一本谈软件架构的书，为什么要设计编程范式呢？Bob大叔如是说：
多态是我们跨越架构边界的手段，函数式编程是我们规范和限制数据存放位置与访问权限的手段，结构化编程则是各模块的算法实现的基础。
这和软件架构的三大关注重点不谋而合：功能性、组件独立性、数据管理。
结构化编程
TODO
面向对象编程
TODO
函数式编程
TODO
4. 设计原则
SRP：单一职责原则
TODO
OCP：开闭原则
TODO
LSP：里氏替换原则
TODO
ISP：接口隔离原则
TODO
DIP：依赖反转原则
TODO
5. 组件构建原则
组件聚合
- REP：复用/发布等同原则
- CCP：共同闭包原则
- CRP：共同复用原则
- 组件聚合原则张力图
组件耦合
- 无依赖环原则
- 自上而下的设计
- 稳定依赖原则
- 稳定抽象原则
6. 整洁架构
TODO：MVP
7. 实现细节
- 数据库是实现细节
- Web是实现细节
- 应用程序框架是实现细节
8. 金玉良言
- 走快的唯一方法是先走好。
- 做一个好的软件架构师所需要的自律和专注程度可能会让大部分程序员始料未及。