架构整洁之道-行业好书-社会科学-太极之巅书单号

书刊介绍

内容简介

《架构整洁之道》是创造“Clean神话”的Bob大叔在架构领域的登峰之作，围绕“架构整洁”这一重要导向，系统地剖析其缘起、内涵及应用场景，涵盖软件研发完整过程及所有核心架构模式。《架构整洁之道》分为6部分，第1部分纲领性地提出软件架构设计的终极目标，描述软件架构设计的重点与模式；第2~4部分从软件开发中三个基础编程范式的定义和特征出发，进一步描述函数、组件、服务设计与实现的定律，以及它们是如何有效构建软件系统的整体架构的；第5部分从整洁架构的定义开始，详细阐述软件架构设计过程中涉及的方方面面，包括划分内部组件边界、应用常见设计模式、避开错误、降低成本、处理特殊情况等，并以实战案例将内容有机整合起来；第6部分讲述具体实现细节；附录则透过作者数十年的软件从业经历再次印证《架构整洁之道》的观点。

对于每一位软件研发从业人员——无论从事的是具体编码实现、架构设计，还是软件研发管理，《架构整洁之道》都是不可或缺的。

作品目录

第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
· · · · · ·

作者简介

Robert C. Martin，Object Mentor公司总裁，面向对象设计、模式、UML、敏捷方法学和极限编程领域的资深顾问。他是Designing Object-Oriented C++ Applications Using the Booch Method 以及 Jolt 获奖图书 Agile Software Development, Principles,Palterns,and Practices(中译版《敏捷软件开发：原则、模式与实践》)《代码整洁之道》等畅销书作者。

译者简介

孙宇聪：曾在谷歌工作多年，任谷歌高级SRE（Senior Site Reliblity Engineer），前Coding.net 技术负责人。

精彩摘录

人渐渐地发现，这个世界上有很多问题就像翘翘板一样，只能要一边，这一边上去了，另边就下来了。就像要么用空间换时间，要么用时间换空间一样，你很难同时满足空间和时间要求的“双利解”；就像CAP的三选二的理论一样，这个世界不存在完美的解方案无论什么方案都有好的一面和不好的一面。而且这些工程师还还渐渐发现，每当引入一个新的技术来解決一个已有的问题时，这个新的技术就会带来更多的问题，问题就像有一个生命体一样，它们会不断地繁殖和进化。

——引自章节：第1部分概述

《架构整洁之道》孙宇聪译，软件架构参考书籍。第一章软件架构的终极目标是，用最小的人力成本来满足构建和维护该系统的需求。软件开发的核心特点:要想跑得快，先要跑得稳。过度自信只会使得重构设计陷入和原项目一样的困局中。研发团队最好的选择是清晰地认识并避开工程师们过度自信的特点，开始认真地对待自己的代码架构，对其质量负责。要想提高自己软件架构的质量，就需要先知道什么是优秀的软件架构。而为了在系统构建过程中采用好的设计和架构以便减少构建成本，提高生产力，又需要先了解系统架构的各种属性与成本和生产力的关系。第二章软件系统两个价值维度-行为价值和架构价值。软件架构师这一职责本身就应该更关注系统的整体结构，而不是具体的功能和系统行为的实现。软件架构师必须创建出一个可以让功能实现起来更容易、修改起来更简单、扩展起来更轻松的软件架构。第四章在架构设计领域，功能性降解拆分仍然是最佳实践之一。第十五章软件架构师自身需要是程序员，并且必须一起坚持做一线程序员，绝对不要听从那些说应该让软件架构师从代码中解放出来以专心解决高阶问题的伪建议。如果不亲身承受因系统设计而带来的麻烦，就体会不到设计不佳所带来的痛苦，接着就会逐渐迷失正确的设计方向。软件架构这项工作的实质就是规划如何将系统切分成组件，并安排好组件之间的排列关系，以及组件之间互相通信的方式。软件架构的终极目标就是最大化程序员的生产力，同时最小化系统的总运营成本。在真正制作出来一个可复用框架之前，是不知道怎么制作一个可复用框架的。想要制作一个可复用的框架，必须要和几个复用该框架的应用一直开发。

——引自第1页