第一部分 简介
第一章
Architecture的简介。
架构设计的目的：减少系统构建和维护的成本。
引入例子对比不同开发思路下维护软件的成本，说明架构的重要性。
第二章
功能开发 VS 架构设计
只注重功能开发不注重架构的系统是无法延续的。
引入Esenhower Matrix，把要做的事按重要程度和紧急程度划分在四个象限，并且排优先级。
架构设计不紧急但是重要，应该放在较高的优先级。
第二部分 编程范式
1. 结构化编程——限制了goto的使用，使得程序的正确性可被证明
2. 面向对象——限制了函数指针的使用，带来了多态，加强了代码依赖的控制，使依赖反转成为可能
3. 函数式编程——限制了赋值语句，把程序隔离成mutable和非mutable的部分，减少竞争、死锁等变量冲突
以上三种编程范式都限制了程序的行为，规范了程序底层的设计原则。
第三部分 设计原则
SOLID 略
规范了程序中层（mid-level）的设计原则
第四部分 组件原则
component是独立部署的最小单位。
component聚合的三原则：
REP: Reuse Release Equivalence Principle. component复用和发布的粒度应该一致。
CCP: Common Closure Principle，component级别的SRP
CRP：Common Reuse principle，component级别的ISP
处理component耦合的三原则：
1. the Acyclic Dependancies Principles：无循环依赖。component依赖关系应该是演进出来的，而不是设计出来的。
2. the Stable Dependencies Principle：不稳定component应该依赖稳定的component
3. the Stable Abstractions Principle：component的抽象程度和稳定程度应当成正比。
第五部分 架构
架构的目标是什么？
1. 功能的正常使用
2. 易于维护
3. 易于开发
4. 易于部署
如何达到这些目标？
通过把系统解耦成彼此独立的component，能让很多技术决策尽可能延后，降低在需求变化时改动系统的成本。
如何进行解耦？
系统的解耦主要有两种方式，一种按用户场景（use case），一种按代码层级结构（layer）。解耦之后，通过用户场景或者代码层级划分的各个component应该保证独立开发和独立部署。
解耦的级别有源码级别、部署级别、服务级别。
解耦之后，如何处理跨component的重复代码？
要识别真正的重复和偶然重复。如果两处相同的代码改动的原因、频繁不相同，那就只是偶然重复。
常见的偶然重复：数据库层的entity和展现层的DTO字段一样；用户场景A和B有相似的Request或者View Model。
划分边界
为了让系统内各组成部分保持独立，需要划分出各部分之间的边界。
业务逻辑是一个系统的核心价值，不应该依赖底层的具体技术细节，比如GUI和数据库。
划分边界的具体技术手段有很多，比如单体应用的内部分离、分离成可独立部署的模块、线程隔离、程序隔离（local processes）、服务。在一个系统里往往会有多种划分边界的方式。
整洁架构（Clean Architecture）
架构应该体现系统的功能，而不是使用的框架。
整洁架构的特点如下：
1. 可测
2. 架构无关
3. UI无关
4. 数据库无关
5. 外部组织无关
测试
测试不应该依赖系统脆弱的部分，比如测业务逻辑依赖GUI。
把难以测试的部分隔离，比如UI展示拆成无逻辑的Humble Object和包含所有显示逻辑的View Model，只针对View Model测试。
为测试提供专门的API验证业务逻辑，以防止测试与具体的实现耦合。
第六部分 细节
web、数据库、框架等等都是底层（low-level）的技术细节（details），上层（top-level）抽象的业务逻辑不应该依赖这些技术细节。要在架构内对核心业务模块屏蔽这些细节。
拾遗章节
程序的分包方式：
1. 按层级划分
2. 按功能划分
3. 端口和适配器
4. 按component划分
要架构的设计思想映射到分包甚至代码实现里，并通过静态的代码检查或者编译限制来强化这些限制。魔鬼总在代码实现里。
相关链接
1. http://butunclebob.com/ArticleS.UncleBob.PrinciplesOfOod
2. https://fideloper.com/hexagonal-architecture
4. https://gist.github.com/ygrenzinger/14812a56b9221c9feca0b3621518635b
