Robert C Martin Uncle Bob 从1970年编程至今。他是 cleancoders.com 的联合创始人，该网站为软件开发者提供在线视频教育。同时，他还是 Unclde Bob 咨询公司 LLC 的创始人，该公司为全球大型公司 提供软件开发咨询服务、培训，以及技能培训服务。同时，他任 8th Light, Inc 的”首席匠人”一职，该公司是位于芝加哥的一家以加软件开发咨询公司。本书作者在各种行业周刊上出版了十余篇文章，同时也是国际会议和行业峰会经常邀请的演讲者。他曾任 C++ Report 的主编三年，并且曾任敏捷联盟Agile Aliance的主席。
Robert C Martin Uncle Bob 从1970年编程至今。他是 cleancoders.com 的联合创始人，该网站为软件开发者提供在线视频教育。同时，他还是 Unclde Bob 咨询公司 LLC 的创始人，该公司为全球大型公司 提供软件开发咨询服务、培训，以及技能培训服务。同时，他任 8th Light, Inc 的”首席匠人”一职，该公司是位于芝加哥的一家以加软件开发咨询公司。本书作者在各种行业周刊上出版了十余篇文章，同时也是国际会议和行业峰会经常邀请的演讲者。他曾任 C++ Report 的主编三年，并且曾任敏捷联盟Agile Aliance的主席。
目錄：
PART I Introduction 1
Chapter 1 What Is Design and Architecture? 3
The Goal? 4
Case Study 5
Conclusion 12
Chapter 2 A Tale of Two Values 13
Behavior 14
Architecture 14
The Greater Value 15
Eisenhowers Matrix 16
Fight for the Architecture 18
PART II Starting with the Bricks： Programming Paradigms 19
Chapter 3 Paradigm Overview 21
Structured Programming 22
Object-Oriented Programming 22
Functional Programming 22
Food for Thought 23
Conclusion 24
Chapter 4 Structured Programming 25
Proof 27
A Harmful Proclamation 28
Functional Decomposition 29
No Formal Proofs 30
Science to the Rescue 30
Tests 31
Conclusion 31
Chapter 5 Object-Oriented Programming 33
Encapsulation? 34
Inheritance? 37
Polymorphism? 40
Conclusion 47
Chapter 6 Functional Programming 49
Squares of Integers 50
Immutability and Architecture 52
Segregation of Mutability 52
Event Sourcing 54
Conclusion 56
PART III Design Principles 57
Chapter 7 SRP： The Single Responsibility Principle 61
Symptom 1： Accidental Duplication 63
Symptom 2： Merges 65
Solutions 66
Conclusion 67
Chapter 8 OCP： The Open-Closed Principle 69
A Thought Experiment 70
Directional Control 74
Information Hiding 74
Conclusion 75
Chapter 9 LSP： The Liskov Substitution Principle 77
Guiding the Use of Inheritance 78
The SquareRectangle Problem 79
LSP and Architecture 80
Example LSP Violation 80
Conclusion 82
Chapter 10 ISP： The Interface Segregation Principle 83
ISP and Language 85
ISP and Architecture 86
Conclusion 86
Chapter 11 DIP： The Dependency Inversion Principle 87
Stable Abstractions 88
Factories 89
Concrete Components 91
Conclusion 91
PART IV Component Principles 93
Chapter 12 Components 95
A Brief History of Components 96
Relocatability 99
Linkers 100
Conclusion 102
Chapter 13 Component Cohesion 103
The ReuseRelease Equivalence Principle 104
The Common Closure Principle 105
The Common Reuse Principle 107
The Tension Diagram for Component Cohesion 108
Conclusion 110
Chapter 14 Component Coupling 111
The Acyclic Dependencies Principle 112
Top-Down Design 118
The Stable Dependencies Principle 120
The Stable Abstractions Principle 126
Conclusion 132
PART V Architecture 133
Chapter 15 What Is Architecture? 135
Development 137
Deployment 138
Operation 138
Maintenance 139
Keeping Options Open 140
Device Independence 142
Junk Mail 144
Physical Addressing 145
Conclusion 146
Chapter 16 Independence 147
Use Cases 148
Operation 149
Development 149
Deployment 150
Leaving Options Open 150
Decoupling Layers 151
Decoupling Use Cases 152
Decoupling Mode 153
Independent Develop-ability 153
Independent Deployability 154
Duplication 154
Decoupling Modes Again 155
Conclusion 158
Chapter 17 Boundaries： Drawing Lines 159
A Couple of Sad Stories 160
FitNesse 163
Which Lines Do You Draw, and When Do You Draw Them? 165
What About Input and Output? 169
Plugin Architecture 170
The Plugin Argument 172
Conclusion 173
Chapter 18 Boundary Anatomy 175
Boundary Crossing 176
The Dreaded Monolith 176
Deployment Components 178
Threads 179
Local Processes 179
Services 180
Conclusion 181
Chapter 19 Policy and Level 183
Level 184
Conclusion 187
Chapter 20 Business Rules 189
Entities 190
Use Cases 191
Request and Response Models 193
Conclusion 194
Chapter 21 Screaming Architecture 195
The Theme of an Architecture 196
The Purpose of an Architecture 197
But What About the Web? 197
Frameworks Are Tools, Not Ways of Life 198
Testable Architectures 198
Conclusion 199
Chapter 22 The Clean Architecture 201
The Dependency Rule 203
A Typical Scenario 207
Conclusion 209
Chapter 23 Presenters and Humble Objects 211
The Humble Object Pattern 212
Presenters and Views 212
Testing and Architecture 213
Database Gateways 214
Data Mappers 214
Service Listeners 215
Conclusion 215
Chapter 24 Partial Boundaries 217
Skip the Last Step 218
One-Dimensional Boundaries 219
Facades 220
Conclusion 220
Chapter 25 Layers and Boundaries 221
Hunt the Wumpus 222
Clean Architecture? 223
Crossing the Streams 226
Splitting the Streams 227
Conclusion 228
Chapter 26 The Main Component 231
The Ultimate Detail 232
Conclusion 237
Chapter 27 Services： Great and Small 239
Service Architecture? 240
Service Benefits? 240
The Kitty Problem 242
Objects to the Rescue 244
Component-Based Services 245
Cross-Cutting Concerns 246
Conclusion 247
Chapter 28 The Test Boundary 249
Tests as System Components 250
Design for Testability 251
The Testing API 252
Conclusion 253
Chapter 29 Clean Embedded Architecture 255
App-titude Test 258
The Target-Hardware Bottleneck 261
Conclusion 273
PART VI Details 275
Chapter 30 The Database Is a Detail 277
Relational Databases 278
Why Are Database Systems So Prevalent? 279
What If There Were No Disk? 280
Details 281
But What about Performance? 281
Anecdote 281
Conclusion 283
Chapter 31 The Web Is a Detail 285
The Endless Pendulum 286
The Upshot 288
Conclusion 289
Chapter 32 Frameworks Are Details 291
Framework Authors 292
Asymmetric Marriage 292
The Risks 293
The Solution 294
I Now Pronounce You 295
Conclusion 295
Chapter 33 Case Study： Video Sales 297
The Product 298
Use Case Analysis 298
Component Architecture 300
Dependency Management 302
Conclusion 302
Chapter 34 The Missing Chapter 303
Package by Layer 304
Package by Feature 306
Ports and Adapters 308
Package by Component 310
The Devil Is in the Implementation Details 315
Organization versus Encapsulation 316
Other Decoupling Modes 319
Conclusion： The Missing Advice 321
PART VII Appendix 323
Appendix A Architecture Archaeology 325
Index 375
內容試閱：
前言
软件架构（Architecture）究竟指的是什么呢？
正向比喻是一种修辞手法，试图用架构的语言来描述某个软件，结果可粗可细，可能会过度描述，也可能会表达不足。
用架构来描述软件的明显优势是可以清晰地描绘其内在的组织结构（structure）。不管是在讨论组件、类、函数、模块（module）、还是层级、服务、微观与宏观的软件开发过程，组织结构都是一个主要关注点。但是真实世界中的许多软件项目并不是按我们的信念和理解生长的它们底层层层嵌套，顶层则往往是一团乱麻，相互纠缠。有的时候真的很难让人相信，软件项目的组织结构性也能像物理建筑那样一目了然，层次清晰。
物理建筑，不管地基是石头还是水泥，高大还是宽阔，宏伟还是渺小，其组织结构都一目了然。物理建筑的组织结构必须被重力这个自然规律以及建筑材料自身的物理特性所约束。用砖头、水泥、木头、钢铁或者玻璃造就的物理建筑与软件项目相比，最大的不同点就是，大型软件项目由软件组件构成，而这些软件组件又由更小的软件组件构成，层层嵌套。
当我们讨论软件架构时，尤其要注意软件项目是具有递归（recursive）和分形（fractal）特点的，最终都要由一行行的代码组成。脱离了一行行的代码，脱离了具体的细节（detail）设计，架构问题就无从谈起。大型物理建筑的组织架构常常是由其中一个个细节设计共同决定的，如果细节设计太多，那么组织架构就会更复杂，反之亦然。但是软件项目的复杂程度却不一定能用物理尺度来衡量。软件项目也有组织结构，不论从数量上还是种类多样性上都远远超过物理建筑。我们可以很明确地说，软件开发比修建物理建筑需要更多、更专注的设计过程，软件架构师比建筑架构师更懂架构！
虽然人类已经习惯了使用物理尺度来衡量和理解现实世界，但这些却不适用于软件项目。不管某个PowerPoint图表中的彩色方块多么好看、多么简单易懂，也无法完全代表一个软件的架构。它只能是某个软件架构的某种展现形式。软件架构并没有一个固定的展现形式，每一种展现形式都建立在背后的层层抉择之上，例如，哪些部分要包含其中，哪些则应该被排除；哪些部分用特殊形状和颜色进行强调，哪些部分则一笔带过，甚至直接忽略。每种表现形式都是对的，它们往往没有任何内在的联系。
虽然软件可能是人凭空编造出来的，但还是要在现实世界中运行。虽然在设计软件架构的过程中物理定律和物理尺度可能并不是主要考虑的对象，但我们还是要理解和遵循某些约束条件。CPU速度和网络带宽往往直接决定了系统的性能。内存和存储的大小限制也会影响代码的设计。
这就是爱的不幸，期待是无穷的，但行动却是有限的，欲望是无止境的，体验却如奴隶般受限。
William Shakespeart
无论如何，我们和我们的公司，乃至于整个经济活动都存在于现实世界中，我们可以利用现实世界的一些准则来衡量和推理软件开发过程中那些不好量化和物化的因素。
软件架构是系统设计过程中所有重要设计决定的集合，其中每个设计决定的重要程度则通过变更成本来衡量。
Grady Booch
时间、金钱以及努力是软件架构中区分规模大小的衡量标准，也是架构和细节的区分标准。通过对这些要素的衡量，我们可以判断某个特定架构是好或坏：一个好的架构，不仅要在某一特定时刻满足软件用户、开发者和所有者的需求，更需要在一段时间以内持续满足他们的后续要求。
如果你觉得好架构的成本太高，那你可以试试差的架构加上返工重来的成本。
Brian Foote，Joseph Yoder
一个系统的常规变更需求成本不应该是昂贵的，也不应该伴随着难以决策的大型设计而调整，更不应该需要一个独立的项目来单独完成。这些常规变更应该可以归入每日或者每周的日常系统维护中去。
要解决这个问题，还有一个不小的物理难题：时间旅行。我们怎么能够知道某个系统未来的变更需求，以便提前做准备呢？我们怎么能在没有水晶球与时间旅行机的情况下，未卜先知，降低未来的变更成本呢？
所谓架构，就是你希望能在项目一开始就做对，但是却不一定能够做对的决策的集合。
Ralph Johnson
了解历史已经够难了，我们对现实的掌握最多也只有七八成，预言未来就更加困难。
我们架构师们每天都站在这样拥有无穷选择的交叉路口。
其中一条比较黑暗的路线认为，只有威权和刚性才能带来强壮稳定的软件架构。如果某项变更成本太高，那么就忽视它变更背后的需求要么被抑制，要么被丢到官僚主义的大机器中绞碎。架构师的决定是完整的、彻底极权的。软件架构就是全体开发人员的反乌托邦噩梦，永远是所有人沮丧的源泉。
而另外一条路线则充斥着大量投机性的通用设计。这会使软件项目中到处都是硬编码的猜测，无穷无尽的参数，或者成篇累牍的无效代码。维护这样的项目，常常遇到意外情况，预留多少资源都不够用。
本书试图探索的是一条极简优美的路线。这条路线认同软件的灵活多变性，并且保证这种灵活多变性仍是系统的一流属性。同时，我们也承认人类并不能全知全晓，但在信息不全的情况下人类仍然能够做出优良决策。这条路线可以使人类的优势发挥作用，而非劣势。通过实际创造和探索，我们提出问题进行实验。优秀的架构一定是要靠一个优良的体系不断打磨才能产生的，并不是一成不变的。
软件架构是一个猜想，只有通过实际部署和测量才能证实。
Tom Gilb
遵循这条路线，我们需要用心、仔细观察，不停观察和思考，重视实践和原则。虽然这可能听起来很麻烦、很耗时，但是只有坚持走下去才能成功。
走得快的唯一方法，是先走好。
Robert C. Martin
一起享受这个过程吧！
Kevlin Henney
2017年5月
序
本书叫作《Clean Architecture：软件结构与设计工匠精神》，使用这个名字可谓十分大胆，甚至可以说是自傲。那么，为什么我会选择写这本书，并且使用这个名字呢？
自1964年，12岁的我写下人生的第一行代码起，到2016年，我编程已经超过50年。在这段时间里，我自认为学到了组织软件系统的一些方法并且相信这些方法和经验对其他人有些价值。
我学习的方法是实际去构建一些大大小小的软件系统。我构建过小型的嵌入式系统，也构建过大型的批处理系统；我构建过实时控制系统，也构建过Web网页系统；我写过命令行程序、图形界面程序、进程管理程序、游戏、计费系统、通信系统、设计工具、画图工具，等等。
我写过单线程程序，也写过多线程程序；我写过由几个重型进程组成的应用，也写过由大量轻型进程组成的应用；我写过跨多个处理器的应用，也写过数据库类、数值计算类、几何计算类以及很多很多其他类型的应用。
回首过去，经历了这么多应用和系统的构建过程，我获得了一个令人震惊的领悟：
软件架构的规则是相同的！
这个领悟的出乎预料之处在于，我所构建的这些系统之间差异巨大。为什么所有这些差异巨大的系统都遵守着同样的软件架构规则呢？我得出的结论是，软件架构规则和其他变量无关。
如果回顾一下过去这半个世纪以来硬件系统产生的巨大变革，这个结论就更惊人了。我的编程生涯起步于像家用冰箱那么大的巨型机，它的CPU周期只有0.5MHz，拥有4KB核心内存，32KB磁盘存储，以及每秒只能传输10个字符的打字机接口。而现在，我正在一辆游览南非的观光车上写这篇序言。我用的MacBook拥有4核i7处理器，每个核心2.8GHz。这台电脑有16GB内存，1TB SSD硬盘，可以用28801800虹膜显示屏展现高清视频。二者在计算能力上有着天壤之别。粗略分析即可知，这台MacBook至少比我半个世纪以前的计算机强大1022倍。
22个数量级所带来的差距是非常非常巨大的，从地球到半人马星座也只有1022埃（angstrom，天文学单位），你口袋里的零钱所含的电子数量也差不多1022个。而这个数字（注意还是至少）是我在一生中，亲身经历的计算能力的提升。
既然计算能力发生了这么巨大的变化，那么其对于我所编写的软件影响有多大呢？软件大小当然变大了。我过去认为2000行的程序就很庞大了。毕竟这样的程序打成纸板能装满一盒子，重量超过10英磅。而现在，一个不超过10万行的程序，都不能算大程序了。
同时，在软件性能上当然也有所提升。我们现在可以轻轻松松地完成1960年只能幻想的事情。电影The Forbin Project、The Moon Is a Harsh Mistress，以及2001： A Space Odyssey都试图预言我们的现状，但是都没那么成功。在这些电影中，获得了智能的巨型机器占据主导，而我们目前所拥有的依然只是计算机，虽然体积之小是当初难以想象的。
同时，还有一点很重要：今天的软件与过去的软件仍然是一样的。都是由if语句、赋值语句、以及while循环组成的。
哦，你可能会抗议说，我们现在有更好的编程语言，以及更高级的编程范式。毕竟，我们现在用Java、C#、Ruby编写程序，并且大量采用面向对象编程方式。这没错，但是最终代码仍然只是顺序执行、分支语句、遍历的组合，这方面和1960年，甚至1950年的程序是一模一样的。
如果深入观察计算机编程的本质，我们就会发现，这50年来，计算机编程基本没有什么大的变化，无非编程语言稍微进步了一点，工具质量大大提升了。但是计算机程序的基本构造没有什么变化。
如果一个1966年的计算机程序员穿越时空
購物車/收銀台(0) | 在線留言板
| 付款方式
| 運費計算
| 聯絡我們
| 幫助中心 |
加入書簽
HOME
新書上架
