《架构整洁之道》笔记

最近在看《架构整洁之道》这本书，记录一下一些笔记。

编程范式

• 面向对象编程：多态是跨越架构边界的手段

• 函数式编程：是规范和限制数据存放位置与访问权限的手段

• 结构化编程：是各个模块的算法实现基础

系统设计原则

系统设计中，模块，组件的关系应该是单向依赖的关系。同时，如果A组件不想被B组件上发生的修改所影响，那么就让B组件依赖于A组件，实现方式是依赖反转

系统在具体实现上，可以分为两部分组件：抽象接口（抽象层）和具体实现（实现层）。

两者之间的边界被称为架构边界，所有跨越这条边界的源代码级别的依赖关系应该都是单向的，即具体实现层依赖抽象层（依赖守则，依赖方向和控制流方向相反，也就是所谓控制反转）。

软件架构

保持可选项（插件式架构）：软件系统在设计实现时，尽可能的让细节与策略脱离关系，在开发高层策略时有意的让自己摆脱具体细节的纠缠，从而允许在具体决策过程中推迟或者延迟与细节相关的内容。例如，设计早期先不关心具体的数据库类型、框架、Web服务器、工具库、依赖注入等等。在一个设计良好的系统架构中，这些细节的决策都应该是辅助性的，可以被推迟的。

策略与层次

在将整体业务策略拆分时，变更原因、时间和层次相同的策略应该被分到同一个组件当中。

各个组件的组合应该是一个有向无环图图，并且，低层次的组件通常被设计为依赖于高层次的组件（这里的“层次”，是指按照与“输入和输出的距离”来定义，一个策略距离系统的输入/输出约远，它的层次就越高）。

层次划分

业务实体层（entity）

业务实体是一个对象，这个对象中包含了一系列用于操作关键数据的业务逻辑，其包含的只有业务逻辑，与数据库、用户界面、第三方框架等内容无关。

业务实体是一个可以适用于多个应用情景的一般化概念。

用例层（usecase）

用例描述的是某种特定应用情景下的业务逻辑，这些逻辑所规范的是用户与业务实体之间的交互方式，其包含了如何调用业务实体中的关键业务逻辑的定义。

用例只控制用户和实体之之间的交互方式，并不描述系统与用户之间的接口。

接口适配器层

接口适配器层负责将数据从对用例和业务实体而言最方便的操作方式，转换成外部系统（例如框架/数据库）最方便操作的格式。

其包含：展示器（presenter）、视图（view）、用例交互器（interactor）、控制器（controller）

展示器与视图

谦卑设计模式：将两类行为拆分成两组模块或类，一组模块被称为谦卑组，其包含了系统中所有难以测试的行为，这些行为已经简化到不能再简化了；另一组模块包含了所有不属于谦卑对象的行为。

视图部分属于难以测试的谦卑对象，只负责将数据填充到 GUI 上，而不应该对数据进行任何处理。

展示器则是可测试的对象，负责从应用程序中接收数据，然后按视图的需要将这些数据格式化。

框架与驱动程序层

一般由工具、数据库、Web 框架等组成。

一个类似的实现