原味素品書系
《Clean Architecture：軟體架構與設計匠藝（英文版）》
【美】Robert C. Martin（羅伯特·C·馬丁） 著
ISBN 978-7-121-34261-5
2018年7月出版
定價：109.00元
424頁
16開
基本介紹
- 書名：Clean Architecture：軟體架構與設計匠藝（英文版）
- 作者：【美】Robert C. Martin（羅伯特·C·馬丁）
- ISBN：978-7-121-34261-5
- 頁數：424頁
- 定價：109元
- 出版社：電子工業出版社
- 出版時間：2018.7
- 裝幀：平裝
- 開本：16開
編輯推薦
√ Bob 大叔傾情力作
√ 跨越半個世紀的極簡架構經驗
√ 顯著提高開發人員生產率
內容提要
通過合理運用軟體架構的通用法則，可以顯著提升開發者在所有軟體系統全生命周期內的生產力。如今，傳奇軟體匠師Robert C. Martin（Bob 大叔），攜暢銷書Clean Code 與The CleanCoder 所獲巨大成功之威，深刻揭示這些法則並親授運用之道。Martin 在《Clean Architecture：軟體架構與設計匠藝（英文版）》中遠不只是在為我們提供選項，他幾乎是在將軟體世界中橫跨半個世紀的各種架構類型的設計經驗傾囊相授，目的是讓讀者既能閱盡所有架構選型，又可通曉其如何決定成敗。Bob 大叔也的確不負厚望，《Clean Architecture：軟體架構與設計匠藝（英文版）》中充滿了直接而有效的解決方案，以供讀者應對所面臨的真正挑戰——那些或最終成就或徹底破壞你項目的挑戰。
目錄
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
作者簡介
Robert C. Martin（Bob大叔）從1970年編程至今。他是cleancoders.com的聯合創始人，該網站為軟體開發者提供線上視頻教育。同時，他還是Bob大叔諮詢公司的創始人，該公司為全球大型公司提供軟體開發諮詢服務、培訓以及技能培訓服務。同時，他在 8th Light公司任“首席匠人”一職，該公司是位於芝加哥的一家軟體開發諮詢公司。本書作者在各種行業周刊上發表了十餘篇文章，同時也經常被國際會議和行業峰會邀請進行演講。他曾任C++ Report的主編，並且曾任敏捷聯盟（Agile Aliance）的主席。
Martin曾經編寫和參與編輯了多本圖書，包括The Clean Coder、Clean Code、UML for Java Programmers、Agile Software Development、Extreme Programming in Practice、More C++ Gems、Pattern Languages of Program Design 3，以及Designing Object Oriented C++ Applications Using the Booch Method。
前言
軟體架構（Architecture）究竟指的是什麼呢？
正向比喻是一種修辭手法，試圖用架構的語言來描述某個軟體，結果可粗可細，可能會過度描述，也可能會表達不足。
用架構來描述軟體的明顯優勢是可以清晰地描繪其內在的組織結構（structure）。不管是在討論組件、類、函式、模組（module）、還是層級、服務、微觀與巨觀的軟體開發過程，組織結構都是一個主要關注點。但是真實世界中的許多軟體項目並不是按我們的信念和理解生長的——它們底層層層嵌套，頂層則往往是一團亂麻，相互糾纏。有的時候真的很難讓人相信，軟體項目的組織結構性也能像物理建築那樣一目了然，層次清晰。
物理建築，不管地基是石頭還是水泥，高大還是寬闊，宏偉還是渺小，其組織結構都一目了然。物理建築的組織結構必須被“重力”這個自然規律以及建築材料自身的物理特性所約束。用磚頭、水泥、木頭、鋼鐵或者玻璃造就的物理建築與軟體項目相比，最大的不同點就是，大型軟體項目由軟體組件構成，而這些軟體組件又由更小的軟體組件構成，層層嵌套。
當我們討論軟體架構時，尤其要注意軟體項目是具有遞歸（recursive）和分形（fractal）特點的，最終都要由一行行的代碼組成。脫離了一行行的代碼，脫離了具體的細節（detail）設計，架構問題就無從談起。大型物理建築的組織架構常常是由其中一個個細節設計共同決定的，如果細節設計太多，那么組織架構就會更複雜，反之亦然。但是軟體項目的複雜程度卻不一定能用物理尺度來衡量。軟體項目也有組織結構，不論從數量上還是種類多樣性上都遠遠超過物理建築。我們可以很明確地說，軟體開發比修建物理建築需要更多、更專注的設計過程，軟體架構師比建築架構師更懂架構！
雖然人類已經習慣了使用物理尺度來衡量和理解現實世界，但這些卻不適用於軟體項目。不管某個PowerPoint圖表中的彩色方塊多么好看、多么簡單易懂，也無法完全代表一個軟體的架構。它只能是某個軟體架構的某種展現形式。軟體架構並沒有一個固定的展現形式，每一種展現形式都建立在背後的層層抉擇之上，例如，哪些部分要包含其中，哪些則應該被排除；哪些部分用特殊形狀和顏色進行強調，哪些部分則一筆帶過，甚至直接忽略。每種表現形式都是對的，它們往往沒有任何內在的聯繫。
雖然軟體可能是人憑空編造出來的，但還是要在現實世界中運行。雖然在設計軟體架構的過程中物理定律和物理尺度可能並不是主要考慮的對象，但我們還是要理解和遵循某些約束條件。CPU速度和網路頻寬往往直接決定了系統的性能。記憶體和存儲的大小限制也會影響代碼的設計。
