CleanArchitecture：软件架构与设计匠艺 pdf下载

　　通过合理运用软件架构的通用法则，可以显著提升开发者在所有软件系统全生命周期内的生产力。如今，传奇软件匠师Robert C.Martin（Bob大叔），携畅销书Clean Code与The Clean Coder所获巨大成功之威，深刻揭示这些法则并亲授运用之道。
　　Martin在《Clean Architecture：软件架构与设计匠艺（英文版）》中远不只是在为我们提供选项，他几乎是在将软件世界中横跨半个世纪的各种架构类型的设计经验倾囊相授，目的是让读者既能阅尽所有架构选型，又可通晓其如何决定成败。Bob大叔也的确不负厚望，《Clean Architecture：软件架构与设计匠艺（英文版）》中充满了直接而有效的解决方案，以供读者应对所面临的真正挑战——那些或最终成就或彻底破坏你项目的挑战。

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
Eisenhower’s 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 Square/Rectangle 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 Reuse/Release 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）设计，架构问题就无从谈起。大型物理建筑的组织架构常常是由其中一个个细节设计共同决定的，如果细节设计太多，那么组织架构就会更复杂，反之亦然。但是软件项目的复杂程度却不一定能用物理尺度来衡量。软件项目也有组织结构，不论从数量上还是种类多样性上都远远超过物理建筑。我们可以很明确地说，软件开发比修建物理建筑需要更多、更专注的设计过程，软件架构师比建筑架构师更懂架构！