架构整洁之道解读

架构的定义

软件架构，是在交付基本功能的基础上，能够使得系统易于开发、部署、运行和维护，用于支撑软件系统的生命周期。在架构设计中要尽可能长时间地保留尽可能多的可选项。

软件架构师必须是程序员，且是一线程序员，并且是能力最强的一线程序员。当然，代码量未必是最多的。

为什么要提编程范式

• 结构化编程是对程序控制权的直接转移的限制（限制了goto）；
• 面向对象编程是对程序控制权的间接转移的限制（限制了函数指针）；
• 函数式编程是对程序中赋值操作的限制（限制了变量多次被赋值，避免临界区的竞态问题）。

相比于软件产生之初，每种范式都是为了约束某种编写代码的方式，没有一种范式是在增加新能力。

编程范式和架构有关系吗？当然有，譬如，面向对象的多态是跨越架构边界的手段，函数式编程是规范和限制数据存放位置与访问权限的手段，结构化编程则是各模块算法实现的基础。这和软件架构的三大关注点不谋而合：功能性、组件独立性以及数据管理。

也就是说，编程范式是一种架构约束。

SOLID扩展到架构维度同样适用

SRP:每个软件模块都有且只有一个被改变的理由；
OCP:软件设计必须允许新增代码来改变系统的行为，而非只能靠修改原来的代码；
LSP:如果想用可替换的组件来构建软件系统，那么这些组件就必须遵守同一个约定，以便让这些组件可以相互替换；
ISP:这项设计原则主要告诫软件设计师应该在设计中避免不必要的依赖；
DIP:该设计原则指出高层策略性代码不应该依赖实现底层细节的代码，相反，那些实现底层细节的代码应该依赖高层策略性代码。DIP将会是这本书的核心思想。

组件

组件聚合

组件是软件的部署单元，是整个软件系统在部署过程中可以独立完成部署的最小实体。例如java的jar，C的so等，或者python的一组源文件。动态链接技术，使得组件化的插件式架构已经成为常见的软件构建形式了。

那么，哪些内容应该归到同一组件内呢？要从几个原则说起：

REP：复用/发布等价原则

软件复用的最小粒度应等同于其发布的最小粒度。即划归到同一组件中的类与模块应该是可以同时发布的。这意味着它们共享相同的版本号和版本跟踪