架构整洁之道

出版者:电子工业出版社

作者:【美】Robert C. Martin（罗伯特 C. 马丁）

出品人:博文视点

页数:348

出版时间:2018-9

价格:99.00元

装帧:平装

isbn号码:9787121347962

具体描述

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

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

作者简介

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 技术负责人。

目录信息

第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
· · · · · · (收起)

读后感

这是一本讲架构设计之道的书； 道理，说简单也简单，就是根据功能的层次和依赖关系解耦合；说复杂也复杂，如何在架构理想和项目现实之间平衡，不是书本可以说清楚学得到的。知易行难是永远难以解决的问题。 作为一个同在PDP11上写出Hello world的老工程师，我对Martin老师所述...  

重提了一遍各种principles。SOLID中S和D的思想贯穿整本书。收获最大的还是D，Dependecy Invsrsion。通过interface（或者说Polymorphism），使得在boundary crossing的时候，“底层”指向“高层”。感觉是从另外一个角度去看待interface如何解耦合。  

用户评价

做为一个没什么架构概念的人，感觉很受启发。

赞赞赞！很好地说明了服务横向、纵向如何划分，核心业务以及周边组件如何关联。架构人的律条

时间带走的只是浮华

最近十年互联网快速的发展，让技术架构的演进屈从于业务发展，而底下一砖一瓦的搭建，未必牢靠。作者有早期软件的开发经验，从更本质的视角描述了对架构设计的理解。直接对比评判不同的大小环境中的方法论意义不大，但思路是可以互相启迪。从这个角度讲，本书的思路未必适用于当下的互联网技术架构设计，却能让人从一种盲从的开发状态中抽出身，考虑下 技术发展趋势中的原因，以及另一种技术发展的可能性。

是也乎,(￣▽￣) 没有隔壁代码简洁之道有用... 架构整洁, 其实, 多数情况, 和开发无关... 社会学的权力 PK 太多了... 所有构想好的架构, 都将在产品的无限肿胀下完全崩溃... 所以, 有 OOP/ODD/DDD/... 各种流派... 其实, 都不过是借口. 将产品功能边界夯死, 一切都将不同.