善用软件架构的通用法则，即可显著提升开发者在所有软件系统全生命周期内的生产力。如今，传奇软件匠师Robert C. Martin（Bob大叔），携畅销书Clean Code与The Clean Coder所获巨大成功之威，向我们深刻揭示了这些法则并亲授运用之道。
Martin在《架构整洁之道》中远不只是在为我们提供选项，他几乎是在将软件世界中横跨半个世纪的各种架构类型的经验倾囊相授，目的是让读者既能阅尽所有架构选型，又可通晓其如何决定成败。Martin也的确不负厚望，本书中充满了直接而有效的解决方案，以供读者应对自己面临的真正挑战——那些或最终成就或彻底破坏项目的挑战。
《架构整洁之道》不可不读，无论读者是现任的还是将来的软件架构师、系统分析师、系统设计师或软件项目经理，或是身负将他人设计落地重任的开发人员，这本书都可以让你们受益匪浅。
《架构整洁之道》是创造“Clean神话”的Bob大叔在架构领域的登峰之作，围绕“架构整洁”这一重要导向，系统地剖析其缘起、内涵及应用场景，涵盖软件研发完整过程及所有核心架构模式。《架构整洁之道》分为6部分，第1部分纲领性地提出软件架构设计的终目标，描述软件架构设计的重点与模式；第2~4部分从软件开发中三个基础编程范式的定义和特征出发，进一步描述函数、组件、服务设计与实现的定律，以及它们是如何有效构建软件系统的整体架构的；第5部分从整洁架构的定义开始，详细阐述软件架构设计过程中涉及的方方面面，包括划分内部组件边界、应用常见设计模式、避开错误、降低成本、处理特殊情况等，并以实战案例将内容有机整合起来；第6部分讲述具体实现细节；附录则透过作者数十年的软件从业经历再次印证《架构整洁之道》的观点。
对于每一位软件研发从业人员——无论从事的是具体编码实现、架构设计，还是软件研发管理，《架构整洁之道》都是不可或缺的。
推荐序一
在我心里，程序员可以分为三个层次：普通程序员、工程师和架构师。
普通程序员是编写代码的人。编写代码的方式有很多，只要能让程序跑起来，能正确地处理业务流程和对数据进行计算，就可以说“会编写代码”。程序员需要熟悉整个程序的逻辑及处理过程，需要熟悉程序语言的特性，还需要熟悉一些计算机操作系统的交互调用方式，才能写出从用户侧交互，到数据和业务逻辑处理，再到与计算机系统交互的代码，有效地把用户信息、数据、业务和计算机串联和拼装出来。
然而，其中一些程序员发现，只让代码跑起来是不够的，因为这个世界是不断变化的，他们发现自己需要花更多的时间来维护代码：增加新的需求，扩展原有的流程，修改已有的功能，优化性能……一个人完全维护不过来，还需要更多的人，于是代码还需要在不同人之间轮转；他们发现代码除了需要跑起来，还需要易读、易扩展、易维护，甚至可以直接重用。于是，这些人使用各种各样的手段和技术不断提高代码的易读性、可扩展性、可维护性和重用性。我们把这些有“洁癖”、有工匠精精、有修养的程序员叫作工程师，工程师不仅仅是在编写代码，他们会用工程的方法来编写代码，以便让编程开发更为高效和快速。他们把编程当成一种设计，一种工业设计，把代码模块化，让这些模块可以更容易地交互拼装和组织，让代码排列整齐——阅读和维护这些代码就像看阅兵式一样舒心畅快。
但是故事还没完，这些拥有工匠精神的工程师们还是难以解决某些问题，这些人渐渐地发现，这个世界上有很多问题就像翘翘板一样，只能要一边，这一边上去了，另一边就下来了。就像要么用空间换时间，要么用时间换空间一样，你很难找到同时满足空间和时间要求的“双利解”；就像CAP的三选二的理论一样，这个世界不存在完美的解决方案，无论什么方案都有好的一面和不好的一面。而且，这些工程师还渐渐发现，每当引入一个新的技术来解决一个已有的问题时，这个新的技术就会带来更多的问题，问题就像有一个生命体一样，它们会不断地繁殖和进化。渐渐地，他们发现，问题的多少和系统的复杂度呈正比，而且不仅是线性正比，还可能呈级数正比，此时就越来越难做技术决定。但是有一些资深的工程师开始站出来挑战这些问题，有的基于业务分析给出平衡的方案，有的开始尝试设计更高级的技术，有的开始设计更灵活的系统，有的则开始简化和轻量化整个系统……这些高智商、经验足、不怕难的工程师们引领着整个行业前行。他们就是架构师！
感觉Bob大叔的系列著作好像也在走这个过程，《代码整洁之道》教你写出易读、可扩展、可维护、可重用的代码，《代码整洁之道：程序员的职业素养》教你怎样变成一个有修养的程序员，而《架构整洁之道》基本上是在描述软件设计的一些理论知识。《架构整洁之道》大体分成三个部分：编程范式（结构化编程、面向对象编程和函数式编程），设计原则（主要是SOLID），以及软件架构（其中讲了很多高屋建翎的内容）。总体来说，这本书中的内容可以让你从微观（代码层面）和宏观（架构层面）两个层面对整个软件设计有一个全面的了解。
但是，如果你想从这本书里找到一些可以立马解决具体问题的工程架构和技术，恐怕你会感到失望。这本书中更多的是一些基础的理论知识，看完后你可能会比较“无感”，因为这些基础知识对于生活在这个高速发展的喜欢快餐文化的社会中的人来说，可能很难理解其中的价值——大多数人的目标不是设计出一个优质的软件或架构，而是快速地解决一个具体的问题，完成自己的工作。然而，可能只有你碰过足够多的壁，掉过足够多的坑，经历过足够多的痛苦后，再来读这本书时，你才会发现本书中的这些“陈旧的知识”是多么充满智慧。而且，如果有一天，你像我这个老家伙一样，看到今天很多很多公司和年轻的程序员还在不断地掉坑和挣扎，你就会明白这些知识的重要性了。
我个人觉得，这本书是架构方面的入门级读物，但也并不适合经验不足的人员学习，这本书更适合的读者群是，有3~5年编程经验、需要入门软件设计和架构的工程师或程序员。
最后，我想留下一个观点和一组问题。
观点：无论是微观世界的代码，还是宏观层面的架构，无论是三种编程范式还是微服务架构，它们都在解决一个问题——分离控制和逻辑。所谓控制就是对程序流转的与业务逻辑无关的代码或系统的控制（如多线程、异步、服务发现、部署、弹性伸缩等），所谓逻辑则是实实在在的业务逻辑，是解决用户问题的逻辑。控制和逻辑构成了整体的软件复杂度，有效地分离控制和逻辑会让你的系统得到最大的简化。
问题：如果你要成为一名架构师，你需要明确地区分几组词语（如何区分它们正是留给你的问题），否则你不可能成为一名合格的工程师或架构师。这几组词语是简单vs.简陋、平衡vs.妥协、迭代vs.半成品。如果你不能很清楚地定义出其中的区别，那么你将很难做出正确的决定，也就不可有成为一名优秀的工程师或架构师。
我相信这个观点和这组问题将有助于你更好地阅读并理解这本书，也会让你进行更多的思考，带着思考读这本书，会让你学到更多！
陈皓
（@左耳朵耗子）
推荐序二
久远的教诲，古老的智慧
如果让你接手一套不稳定但要紧的在线系统，这套系统还有各种问题：变量命名非常随意，依赖逻辑错综复杂，层次结构乱七八糟，部署流程一塌糊涂，监控系统一片空白……你该怎么办？
前几年我就遇到了这种问题，我对着频发的故障仔细观察，发现了最关键的问题：如果放着不动，这套系统的核心功能还是相对稳定的，但经常会有一些外围需求要开发，这时由于原有的依赖逻辑和层次结构不够清楚，就会导致“牵一发而动全身”的情况，加上测试不完善，所以几乎每次外围功能上线更新，核心功能都会受影响，然后又要重复好几次“调试→改正→上线”的流程。
怎么办？大家说了很多办法：把单元测试都补全，重构代码拆分核心功能和非核心功能，跟业务方谈暂停需求……这些办法都很对，但是，都需要时间才能见效，而我们最缺的就是时间。
我提了一个很“笨”的办法：把所有“共享变量”都抽到Redis中进行读写，消灭本地副本，然后把稳定版本程序多部署几份，这样就可以多启动几个实例，将这些实例标记为AB两组。同时，在前面搭建代理服务，用于分流请求——核心功能请求分配到A组（程序基本不更新），外围功能请求分配到B组（程序按业务需求更新）。这样做看起来有点多此一举——AB两组都只有部分代码提供服务，而且要通过Redis共享状态，但是却实现了无论B组的程序如何更新，都不会影响A组所承载的核心服务的目的。
虽然当时不少人说“怎么能这样玩呢”，但它确实有效。当天部署，当天生效，在线服务迅速稳定下来，即便新开发的外围功能有问题，核心服务也不受任何影响。这样业务人员满意了，开发人员也可以安心对系统做改造了。
后来有不少人问我是怎么想到这个办法的，答案是：因为我是个老程序员，成长在面向对象的年代，运用SOC（关注点分离）、SRP（单一职责原则）、OCP（开闭原则）这些东西对我来说就如同本能。具体到这个例子，无非就是识别关注点、隔离责任、保持核心关注点的封闭而已。
后来我才知道，我提出的这个方法有个专门的名字叫“蓝绿部署”。当然我自认是个老程序员，不懂这些新鲜概念也不太要紧。确实，如今不少程序员已经不认识SOC、SRP、OCP、LSP等“古老”的玩意了，大家熟悉的是各种语言、类库、框架、代码托管网站。互联网开发场景千变万化，技术一日千里，而面向对象在不少人的脑海里早就是弃之不用的老古董了。只有“老一辈”的程序员还记得那些古老的教诲，守着那些古拙的技巧。但是这些东西，总有一天会被时代淘汰吗？
实际上，这也是我初读《架构整洁之道》的疑惑。虽然Bob大叔这个名字对我们这些“老程序员”来说可谓如雷贯耳，之前针对一般性软件开发所著的《代码整洁之道》和《代码整洁之道：程序员的职业素养》也确实很受欢迎，但如今写架构，还从结构化编程、面向对象编程、函数式编程写起，还花时间解释SRP、OCP、LSP等原则，实在难掩“古老”的感觉。请问，它们和如今的“架构”有什么关系吗？
不过，如果你耐心读下去就会发现，还真有关系。按照Bob大叔的说法，所谓架构就是“用最小的人力成本来满足构建和维护系统需求”的设计行为。以前的面向对象系统和如今的分布式系统，在这一点上是完全一致的。听取久远的教诲，尊重古老的智慧，如今的架构师也会从中受益。不信？我们就拿经典的三个编程范式来举例，看看这些“老掉牙”的玩意儿和如今的架构设计有什么关联。
大家对结构化编程的一般理解是，由if-else、switch-case之类的语句组织程序代码的编程方式，它杜绝了goto导致的混乱。但是从更深的层次上看，它也是一种设计范式，避免随意使用goto，使用if-else、switch-case之类控制语句和函数、子函数组织起来的程序代码，可以保证程序的结构是清楚的，自顶向下层层细化，消灭了杂错，杜绝了混淆。
联系如今的分布式系统，我们在设计的时候，真的能够做到自顶向下层层细化吗？有多少次，我看到的系统设计图里，根本没有“层次”的概念，各个模块没有一致的层次划分，与子系统交互的不是子系统，而是一盘散沙式的接口，甚至接口之间随意互调、关系乱成一团麻的情况也时常出现，带来的就是维护和调试的噩梦。吹散历史的迷雾，不正是古老的goto陷阱的再现吗？
大家对面向对象编程的一般理解是，由封装、继承、多态三种特性支持的，包含类、接口等若干概念的编程方式。但是从更深的层次上看，它也是一种设计范式。多态大概算其中最神奇的特性了，程序员在确定接口时做好抽象，代码就可以很灵活，遇到新情况时，新写一个实现就可以无缝对接。
联系如今的分布式系统，我们在设计的时候，真的能够做到接口足够抽象、新模块能无缝对接吗？有多少次，我看到接口的设计非常随意，接口不是基于行为而是基于特定场景的实现，没有做适当的抽象，也没有为未来预留空间，直接导致契约僵硬死板。每新增一种终端呈现形式，整个内容生产流程就要大动干戈，这样的例子并不罕见。抹去历史的尘埃，这不正是“多态”出现之前的困境吗？
大家对函数式编程的一般理解是，以函数为基本单元，没有变量（更准确地说是不能重复赋值）也没有副作用的编程方式。但是从更深的层次上看，它彻底隔离了可变性，变量或者状态默认就是不可变的，如果要变化，则必须经过合理设计的专门机制来实现。所以，它也避免了死锁、状态冲突等众多麻烦。
联系如今的分布式系统，我们在设计的时候，真的能够彻底隔离可变性、避免状态冲突吗？有多少次，我看到状态或变量的修改接口大方暴露，被不经意（或者恶意）修改，导致奇怪的故障。Bob大叔举了一个相当有趣的例子，如果又要保证操作原子性又要能精确还原各时刻的状态，有个办法是这样的：只提供CR操作，而不提供完整的CRUD操作（就像MySQL的binlog那样）。平时只要追加操作记录即可，各时刻的状态永远通过重放之前的操作记录得出，这样就彻底避免了状态的错乱。这个办法看起来古怪，但我真的在之前的开发中用过（当然是在程序生命周期有限的场景下），而且真的从没出过错。
坦白说，看完《架构整洁之道》这本书，我心里好受点了。因为我发现，我们这些老程序员的知识其实没有过时，如今不少光鲜的架构其实要解决的还是那些古老的问题。多亏了Bob大叔的妙手点拨，我才能穿越时空，享受到“重新发现智慧”的愉悦。
当然，架构设计是一门复杂的学问，要综合考虑编码、质量、部署、发布、运维、排障、升级等等各种因素，做出权衡。好消息是，Bob大叔的这本书覆盖面广，涉及各个方面，相信你认真读完全书一定会和我一样有不小的收获。唯一的问题是，你要适应这个老程序员的口吻和节奏：他当然也会拿如今流行的打车系统做例子，但他更熟悉的还是链接器、C语言、UML图等玩意。
不过我觉得，这都不是大问题。看得出类之间的依赖关系不合理，自然容易发现子系统之间的依赖关系不合理；搞得懂UNIX如何巧妙定义通用的IO设备，自然容易想到对PC Web、Mobile Web、App内的页面做适当抽象；认得清各线程、进程、链接库的职责，自然容易明白微服务也需要避免跨边界调用。更妙的是，从这种古老的视角看问题，往往更能摆脱细节的困扰，把握问题的核心。就像老子说的那样：治大国如烹小鲜。
噢，对了，“治大国如烹小鲜”也是久远的教诲，也包含着古老的智慧。
余 晟
公众号“余晟以为”（yurii-says）作者
现在沪江教育集团担任平台架构部负责人
第1部分 概述
第1章 设计与架构究竟是什么 3
目标是什么 4
案例分析 5
本章小结 11
第2章 两个价值维度 12
行为价值 13
架构价值 13
哪个价值维度更重要 14
艾森豪威尔矩阵 15
为好的软件架构而持续斗争 16
第2部分 从基础构件开始：编程范式
第3章 编程范式总览 21
结构化编程 22
面向对象编程 22
函数式编程 23
仅供思考 23
本章小结 24
第4章 结构化编程 25
可推导性 26
goto是有害的 28
功能性降解拆分 29
形式化证明没有发生 29
科学来救场 29
测试 30
本章小结 31
第5章 面向对象编程 32
封装 33
继承 36
多态 38
本章小结 44
第6章 函数式编程 45
整数平方 46
不可变性与软件架构 47
可变性的隔离 48
事件溯源 49
本章小结 51
第3部分 设计原则
第7章 SRP：单一职责原则 56
反面案例2：代码合并 59
解决方案 60
本章小结 61
第8章 OCP：开闭原则 62
思想实验 63
依赖方向的控制 67
信息隐藏 67
本章小结 67
第9章 LSP：里氏替换原则 68
继承的使用指导 69
正方形/长方形问题 70
LSP与软件架构 70
违反LSP的案例 71
本章小结 73
第10章 ISP：接口隔离原则 74
ISP与编程语言 76
ISP与软件架构 76
本章小结 77
第11章 DIP：依赖反转原则 78
稳定的抽象层 79
工厂模式 80
具体实现组件 82
本章小结 82
第4部分 组件构建原则
第12章 组件 84
组件发展史 85
重定位技术 88
链接器 88
本章小结 90
第13章 组件聚合 91
复用/发布等同原则 92
共同闭包原则 93
共同复用原则 94
组件聚合张力图 95
本章小结 97
第14章 组件耦合 98
无依赖环原则 99
自上而下的设计 105
稳定依赖原则 106
稳定抽象原则 112
本章小结 117
第5部分 软件架构
第15章 什么是软件架构 120
开发（Development） 122
部署（Deployment） 123
运行（Operation） 123
维护（Maintenance） 124
保持可选项 124
设备无关性 126
垃圾邮件 128
物理地址寻址 129
本章小结 130
第16章 独立性 131
用例 132
运行 133
开发 133
部署 134
保留可选项 134
按层解耦 135
用例的解耦 136
解耦的模式 136
开发的独立性 137
部署的独立性 137
重复 138
再谈解耦模式 139
本章小结 141
第17章 划分边界 142
几个悲伤的故事 143
FitNesse 146
应在何时、何处画这些线 148
输入和输出怎么办 151
插件式架构 152
插件式架构的好处 153
本章小结 154
第18章 边界剖析 155
跨边界调用 156
令人生畏的单体结构 156
部署层次的组件 158
线程 159
本地进程 159
服务 160
本章小结 161
第19章 策略与层次 162
层次（Level） 163
本章小结 166
第20章 业务逻辑 167
业务实体 168
用例 169
请求和响应模型 171
本章小结 172
第21章 尖叫的软件架构 173
架构设计的主题 174
架构设计的核心目标 175
那Web呢 175
框架是工具而不是生活信条 175
可测试的架构设计 176
本章小结 176
第22章 整洁架构 177
依赖关系规则 179
一个常见的应用场景 183
本章小结 184
第23章 展示器和谦卑对象 185
谦卑对象模式 186
展示器与视图 186
测试与架构 187
数据库网关 188
数据映射器 188
服务监听器 189
本章小结 189
第24章 不完全边界 190
省掉最后一步 191
单向边界 192
门户模式 193
本章小结 193
第25章 层次与边界 194
基于文本的冒险游戏：Hunt The Wumpus 195
可否采用整洁架构 196
交汇数据流 199
数据流的分割 199
本章小结 201
第26章 Main组件 203
最细节化的部分 204
本章小结 208
第27章 服务：宏观与微观 209
面向服务的架构 210
服务所带来的好处 210
运送猫咪的难题 212
对象化是救星 213
基于组件的服务 215
横跨型变更 216
本章小结 216
第28章 测试边界 217
测试也是一种系统组件 218
可测试性设计 219
测试专用API 220
本章小结 221
第29章 整洁的嵌入式架构 222
“程序适用测试”测试 225
目标硬件瓶颈 228
本章小结 238
第6部分 实现细节
第30章 数据库只是实现细节 240
关系型数据库 241
为什么数据库系统如此流行 242
假设磁盘不存在会怎样 243
实现细节 243
但性能怎么办呢 244
一段轶事 244
本章小结 246
第31章 Web是实现细节 247
无尽的钟摆 248
总结一下 250
本章小结 251
第32章 应用程序框架是实现细节 252
框架作者 253
单向婚姻 253
风险 254
解决方案 255
不得不接受的依赖 255
本章小结 256
第33章 案例分析：视频销售网站 257
产品 258
用例分析 258
组件架构 260
依赖关系管理 261
本章小结 262
第34章 拾遗 263
按层封装 264
按功能封装 266
端口和适配器 268
按组件封装 270
具体实现细节中的陷阱 274
组织形式与封装的区别 275
其他的解耦合模式 277
本章小结：本书拾遗 279
后序 280
附录A 架构设计考古 283
