第15章 什么是软件架构
如果想设计一个便于推进各项工作的系统，其策略就是要在设计中尽可能长时间地保留尽可能多的选项。
- 开发（Development）
- 部署（Deployment）
- 运行（Operation）
- 维护（Maintenance）
优秀的架构师会小心地将软件的高层策略与其底层实现隔离开，让高层策略与实现细节脱钩，使其策略部分完全不需要关心底层细节。
第16章 独立性
一个良好的软件架构必须支持以下几点
- 系统的用例与正常运行
- 系统的维护
- 系统的开发
- 系统的部署
- 源码层次
- 部署层次
- 服务层次
第17章 划分边界
软件架构设计本身就是一门划分边界的艺术
为了在软件构构中画边界线，我们需要先将系统分割成组件，其中一部分是系统的核心业务逻辑组件，而另一部分则是与核心业务无关但负责提供必要功能的插件。然后通过对源代码的个性，让这些非核心组件依赖于系统的核心业务逻辑组件。
这也是一种对依赖反转原则（DIP）和稳定抽象原则（SAP）的具体应用。
第18章 边界剖析
按部署层次的组件划分，按线程划分，按本地进程划分，按服务划分。
除单体结构以外，大部分系统都会同时采用多种边界划分策略。一个按照服务层次划分边界的系统也可能会在某一部分采用本地进程的边界划分模式。
第19章 策略与层次
层次（level）： 一条策略距离系统的输入/输出越远，他所属的层次就越高。而直接发管理输入/输出的策略在txxi中的层次是最低的。
通过将策略隔离，并让源码中的依赖方向都统一调整为指向高层策略，
第20章 业务逻辑
业务实体：关键业务逻辑和关键业务数据是紧密相关的，所以它们很适合被放在同一个对象中处理。我们将这种对象称为“业务实体（Entity）”。
- 用例 包含了对如何调用业务实体中的关键业务逻辑的定义。简而言之，用例控制着业务实体之间的交互方式。
这些业务逻辑应该保持纯净，不要掺杂用户蜀面或者所使用的数据库相关的东西。在理想情况下，这部分代表业务逻辑的代码应该是整个系统的核心，其他低层概念的实现应该以插件的形式接入系统中。业务逻辑应该是系统中最独立、复用性最高的代码。
第21章 尖叫的软件架构
- 一个良好的架构设计应该围绕着用例来展开，这样的架构设计可以在脱离框架、工具以及使用环境下完整地描述用例。
良好的架构设计应该尽可能地允许用户推迟和延后决定采用什么框架、数据库、Web服务以及其地与环境相关的工具。 - 一个系统的架构应该着重于展示系统本身的设计，而并非系统所使用的框架。
第22章 整洁架构
- 图片来自 （https://www.zhihu.com/question/301498382/answer/527555292） *
图中为四层同心圆，从内向外依次为： - Entity（业务实体），系统级业务逻辑；
- User Cases（用例），应用级业务逻辑；
- Controller（控制器）；Presenters（展示器）；Gateways（网关）： 接口适配器；
- Web/UI(用户界面)/Extenal Interfaces(外部接口)/DB(数据库)/Devices(设备):框架与驱动程序
** 通常越靠近中心，其所在的软件层次就越高。** 基本上，外层圆代表的是机制，内层圆代表的是策略。
架构设计的规则，即它的依赖关系规则：
** 源码中的依赖关系必须只指向同心圆的内层，即由低层机制指向高层策略。 **
业务实体：业务实体这一层中封装的是整个系统的关键业务逻辑，一个业务实体既可以是一个带有方法的对象，也可是一组数据结构和函数的集合。无论如何，只要它能被系统中的其他不同应用复用就可以。如果我们写的不是一个大型系统，而是一个单一应用的话，那么我们的业务实体就是该应用的业务对象。这些对象封装了该应用中最通用/最高层的业务逻辑，** 它们应该属于系统中最不容易受外界影响而变动的部分。 **
用例：软件的用例层中通常包含的是特定应用场景下的业务逻辑，这里面封装并实现了整个系统的所有用例。这些用例引导了数据在业务实体之间的流入/流出，并指挥着业务实体利用其中的关键业务逻辑来实现用例的设计目标。既不希望这一层所发生的变更影响业务实体，同时也不希望这一层受外部因素（譬如数据库、UI、常框架）的影响。用例应该与它们都保持隔离。
接口适配器：软件的接口适配器通常是一组数据转换器，它们负责将数据从对用例和业务实体而言最方便操作的格式，转化成外部系统最方便操作的格式。
框架与驱动程序：框架与驱动程序层中包含了所有的实现细节。Web是一个实现细节，数据库也是一个实现细节。
跨越边界：假设某些用例需要调用展示器，这里一定不能直接发调用，因为这亲做会违反依赖关系原则：内层圆中的代码不能引用其外层的声明。我们需要让业务逻辑代码调用一个内层接口，并让展示器来负责实现这个接口。我们可以采用这种方式跨越系统中所有的架构边界。利用动态多态技术，我们将源码中的依整关系与控制流的方向中进行反转。不管控制流原本的方向如何，我们都可以让安遵守依整关系原则。
第23章 展示器和谦卑对象
展示器实际上是采用谦卑对象（humble object）模式的一种形式。
我们将系统分割成可测试和不可测试两部分的过程常常就也定义了系统的架构边界。
第24章 不完全边界
架构师的职责之一就是预判未来哪里有可能会需要设置架构边界，并决定应该以完全形式还是不完全形式来实现它们。
- 省掉最后一步：构建不完全边界的一种试就是在将系统分割成一系列可以独立编译、独立部署的组件之后，再把它们构建成一个组件。
- 单向边界： 策略模式
- 门户模式：
第25章 层次与边界
我们不能在项目开始时就决定好哪里需要设计边界，哪里不需要。相关，架构师必须持续观察系统的深埋，时刻注意哪里可能需要设计边界，然后仔细观察这些地方会由于不存在边界而出现哪些问题。
第26章 Main 组件
在所有系统中，都至少要有一个组件来负责创建、协调、监督其他组件的运转。我们将其称为Main组件。
我们在这里的重点是要说明Main组件是整个系统中的一个底层模块，它处于整洁架构的最外圈，主要负责为系统加载所有必要的信息，然后再将控制权转交回系统的最高组件。
Main组件也可被视为程序的一个插件--这个插件负责设置起始状态、配置信息、加载外部资源，最后将控制权转交给应用程序的其他高层组件。
第27章 服务：宏面与微观
另然服务化可能有助于提升系统的可扩展性和可研发性，但服务本身却并不能代表整个系统的架构设计。系统的架构是由系统内部的架构边界，以及边界之间的依赖关系所定义的。与系统中各组件之间的调用和通信方式无关。
一个服务可能是一个独立组件，以系统架构边界的形式融开。一个服务也可能由几个组件组成，其中的组件以架构边界的形式互相隔离。
第28章 测试边界
测试代码也是系统的一部分。测试组件也是要遵守依赖关系原则的，所以它始终都是向内依赖于被测试部分的代码的。
不要依赖于多变的东西----譬如，GUI往往是多变的，因此通过GUI来验证系统的测试一定是脆弱的。
测试专用API，该API应该成为用户界面所用到的交互器与接口适配器的一个超集。
测试专用API的作用就是将应用程序与测试代码解耦。这样，我们的产品代码就可以在不影响测试的情况下进行重构和演进。同样的，这种设计也允许测试代码在不影响生产代码的情况下进行重构和演进。
第29章 整结的嵌入式架构
虽然软件本身并不会随时间推移而磨损，但研件及其固件却会随时间推移而过时，随即也需要对软件做相应的改进。
Kent Beck描述了软件构建过程中的三个阶段：
1、先让代码工作起来----如果代码不工作，就不能产生价值
2、然后再试图将它变好---通过对代码进行重构，让我们自己和其他人更好地理解代码，并能按照需求不断地修改代码。
3、最后再试着让它运行得更快---按照性能提升的”需求“来重构代码。