整洁架构之道

适读人群 ：软件架构师、软件开发人员、软件系统设计人员和软件管理人员
传奇软件巨匠Bob大叔Robert C. Martin将在本书中展示如何为应用程序架构和设计带来更高的专业性和规范性。
通过阅读本书，你将:
了解软件架构师需要具备的能力，以及拥有这些能力的核心准则和实践。
掌握函数处理、组件分离和数据管理所需的基本软件设计原则。
了解编程范式如何通过限制开发者行为来制定统一规范。
理解在设计过程中什么是至关重要的“细节”。
定义适当的边界和层次，并提供组件和服务。
了解设计和架构出错的原因，以及如何预防（或修复）这些错误。

这是一本关于如何设计更整洁、更高效的软件架构的全面、实用性指南，阐述了软件架构师的角色和目标，软件架构设计的核心原则，如何为Web、数据库、客户端、控制台和嵌入式应用程序设计最佳的高级结构。
全书分为六部分，涵盖了设计和架构、编程范式（结构化编程、面向对象编程、函数式编程）、设计原则（单一职责原则、开闭原则、里氏替换原则、接口隔离原则）、组件原则（重定位技术、组件内聚、组件耦合）、架构（独立性、划分边界、边界剖析、分层和边界、整洁架构、整洁嵌入式架构），以及实现细节和案例研究。
本书是软件架构师、系统分析师、系统设计师、软件经理以及执行他人设计的程序员的必读之作。

Robert C. Martin（Bob大叔）　世界著名编程大师，敏捷开发和设计模式先驱，从事软件开发相关工作超过50年。他是“SOLID五大原则”的奠基人、“敏捷宣言”联合签署人、“敏捷联盟”首任主席、C++ Report杂志前主编。他发表了大量有影响力的文章，并经常受邀在许多国际软件大会上发表演讲。他创立了Uncle Bob Consulting有限责任公司，并与儿子Micah Martin共同创立了Clean Coders有限责任公司。他还是Clean Code、The Clean Coder和Functional Design等多本畅销书籍的作者。

推荐序
前言
作者简介

第一部分　概述
第1章　架构与设计　3
我们的目标是什么　4
案例学习　5
本章小结　10

第2章　两种价值维度　11
行为价值　12
架构价值　12
哪个价值维度更重要　13
艾森豪威尔矩阵　14
为架构而战　15

第二部分　从基础构件开始：编程范式
第3章　范式概述　19
结构化编程　20
面向对象编程　20
函数式编程　20
思想小插曲　21
本章小结　21

第4章　结构化编程　22
可推导性　23
有害的goto　25
功能性降解拆分　26
形式化证明没有发生　26
依靠科学来拯救　26
测试　27
本章小结　28

第5章　面向对象编程　29
什么是封装　30
什么是继承　33
什么是多态　35
本章小结　40
第6章　函数式编程　41
整数的平方　42
不可变性与软件架构　43
可变性的隔离　44
事件溯源　45
本章小结　46

第三部分　设计原则
第7章　SRP：单一职责原则　49
反例1：意外的复用　50
反例2：代码合并　52
解决方案　52
本章小结　54

第8章　OCP：开闭原则　55
思想实验　56
依赖方向的控制　59
信息隐藏　59
本章小结　59

第9章　LSP：里氏替换原则　60
继承的使用指南　61
正方形/矩形问题　61
LSP和架构　62
违反LSP的示例　63
本章小结　64

第10章　ISP：接口隔离原则　65
ISP和编程语言　66
ISP和架构　67
本章小结　67

第11章　DIP：依赖反转原则　68
稳定的抽象　69
工厂模式　70
具体实现组件　71
本章小结　71

第四部分　组件原则
第12章　组件　75
组件简史　76
重定位技术　78
链接器　79
本章小结　80

第13章　组件内聚　81
复用/发布等价原则　82
共同闭合原则　83
共同复用原则　84
组件内聚张力图　85
本章小结　86

第14章　组件耦合　87
无依赖环原则　88
自顶向下的设计　93
稳定依赖原则　94
稳定抽象原则　99
本章小结　104

第五部分　架构
第15章　架构的定义　106
开发　108
部署　108
操作　109
运维　109
对可选项保持开放　110
设备独立性　111
垃圾邮件　113
物理寻址　114
本章小结　115

第16章　独立性　116
用例　117
操作　117
开发　118
部署　118
保持选项开放　119
层级解耦　119
解耦用例　120
解耦模式　120
可独立开发性　121
可独立部署性　121
复制　122
又一个解耦模式　123
本章小结　124

第17章　划分边界　125
几个悲伤的故事　126
菲特内斯公司　128
画哪些边界？画在哪里？　130
输入和输出　132
插件化架构　133
关于插件化的争论　134
本章小结　135

第18章　边界剖析　136
跨越边界　137
可怕的单体应用　137
部署组件　139
线程　139
本地进程　140
服务　140
本章小结　141

第19章　策略和级别　142
级别　143
本章小结　145

第20章　业务规则　146
实体　147
用例　148
请求和响应模型　150
本章小结　150

第21章　架构的自白　151
架构的主题　152
架构的目的　152
Web是架构吗　153
框架是工具，而不是生活方式　153
可测试的架构　154
本章小结　154

第22章　整洁架构　155
依赖规则　156
典型场景　160
本章小结　161

第23章　展示器和谦逊对象　162
谦逊对象模式　163
展示器和视图　163
测试和架构　164
数据库网关　164
数据映射　165
服务监听器　165
本章小结　165

第24章　不完全边界　166
跳到最后一步　167
单向边界　168
外观　168
本章小结　169

第25章　分层和边界　170
狩猎游戏　171
整洁架构　172
交汇数据流　174
数据流的分割　174
本章小结　176

第26章　Main组件　178
终极细节　179
本章小结　183

第27章　服务：宏观与微观　184
面向服务的架构　185
服务化所带来的好处　185
运送小猫的难题　187
对象化是救星　188
基于组件的服务　189
跨领域问题　190
本章小结　191

第28章　测试边界　193
测试也是一种系统组件　194
可测试性设计　194
测试专用API　195
本章小结　196

第29章　整洁嵌入式架构　197
程序适用测试　200
目标硬件瓶颈　202
本章小结　210

第六部分　实现细节

第30章　数据库只是实现细节　212
关系型数据库 213

数据库系统为什么如此流行 213

假如没有磁盘 214

实现细节 215

数据存储的性能 215

轶事 215

本章小结 217

第31章　Web 只是实现细节 218

无尽的钟摆 219

要点 220

本章小结 221

第32章　 应用程序框架只是

实现细节 222

框架开发者 223

不对等的关系 223

风险 224

解决方案 224

主动做出选择 225

本章小结 225

第33章　案例研究：

视频销售 226

产品 227

用例分析 227

组件架构 228

依赖管理 230

本章小结 230

第34章　细节决定成败 231

按层组包 232

按功能组包 233

端口和适配器 234

按组件组包 235

实现细节 239

组织方式与封装 239

其他解耦模式 242

本章小结 243

附录　架构考古学 244

本书的书名是整洁架构之道（Clean Architecture），这是一个大胆的名字。一些人甚至会觉得有些傲慢。那么为什么选择这个书名，为什么写本书呢？
我在12岁就写下了人生中的第一行代码。在半个多世纪的代码生涯中我学到了一些关于如何构建软件系统的知识—我相信其他人也会发现这些知识很有价值。我们可以通过构建多个系统（大型和小型）来学习这些知识。我已经创建了小型嵌入式系统和大型批处理系统、实时系统和Web系统、控制台应用程序、GUI应用程序、过程控制应用程序、游戏、会计系统、电信系统、设计工具、绘图应用程序等许多其他应用程序。
此外，还构建了单线程应用程序、多线程应用程序、少量重量级进程应用程序、多轻量级进程应用程序、多处理器应用程序、数据库应用程序、数学应用程序、计算几何应用程序，以及许多其他类型的应用程序。
至此，我已经构建了很多应用程序和系统。通过考虑它们所有的方面，我学到了令人惊讶的知识。构建规则是一样的！这很令人吃惊，因为我构建的系统都是不同的。为什么这些不同的系统都拥有类似的构建规则？我的结论是，软件架构的构建规则独立于其他任何变量。
考虑到半个多世纪以来硬件发生的变化，这更加令人震惊。当我开始编程的时候，使用的是冰箱大小的机器，它有半兆赫的循环时间、4KB的核心内存、32KB的磁盘内存，以及每秒10个字符的电传打印接口。而我现在使用的是一台装有四个i7内核，每个内核运行速度为2.8 GHz的MacBook。它具有16 GB的内存，一台千兆字节的SSD，以及一个2880×1800像素的视网膜显示器，可以显示极高清晰度的视频。计算能力的差距是惊人的。
所有这些计算能力的巨大变化，对我编写软件有什么影响呢？我曾经认为2000行是一个大程序。毕竟，那是一整盒重量近10斤的卡片。但是现在，一个程序直到超过10万行才算真正庞大。软件的性能也得到了显著提升。现在的软件和之前的软件由同样的元素构成，这些元素包括if语句、赋值语句以及while循环。
你可能会反对说，我们有更好的编程语言和更优秀的范式。毕竟，我们使用Java、C#或Ruby进行编程，并且使用面向对象的设计。没错，但代码仍然只是一系列的顺序、选择和迭代，就像在20世纪50年代和60年代一样。当你仔细观察编程实践时，你会意识到在过去50年里几乎没有什么变化。编程语言变得更好了，工具也变得更加出色了，但计算机程序的基本构建块并没有变化。
如果把一个1966年的程序员带到2016年，让她 面对运行Java程序的MacBook，她可能需要24小时才能从震惊中恢复过来。但之后她将能够编写代码。Java与C并没有太大的不同。如果我把你带回1966年，并向你展示使用每秒10个字符的电传打字机打孔纸带来编写和编辑PDP-8代码，你可能需要24小时才能从失望中恢复过来。但随后你将能够编写代码。代码并没有改变太多。
这就是秘密所在：代码的不变性是软件架构规则在系统类型上如此一致的原因。软件架构规则是程序构建块的排序和组装规则。由于这些构建块是通用的并且没有改变，因此排序它们的规则也是普遍且不变的。
年轻的程序员可能会认为这是无稽之谈。他们可能会坚称现在一切都是新的和不同的，过去的规则已经过去了。如果他们这么认为，那就大错特错了。规则没有改变。尽管有了新语言、新框架和新范例，规则还是和1946年艾伦·图灵写下第一部机器代码时一样。
但有一件事情改变了：那时，我们不知道规则是什么。因此，我们一次又一次地违反规则。现在，半个世纪的经验告诉我们，我们掌握了这些规则。
本书讲的就是那些永恒、不变的规则。