Clean Architecture

书名:Clean ArchitectureACraftsman'sGuidetoSoftwareStructureandDesign
作者:RobertC.Martin
译者:
ISBN:9780134494166
出版社:PrenticeHall
出版时间:2017-9-20
格式:epub/mobi/azw3/pdf
页数:432
豆瓣评分: 8.7

书籍简介:

Practical Software Architecture Solutions from the Legendary Robert C. Martin (“Uncle Bob”) By applying universal rules of software architecture, you can dramatically improve developer productivity throughout the life of any software system. Now, building upon the success of his best-selling books Clean Code and The Clean Coder, legendary software craftsman Robert C. Martin (“Uncle Bob”) reveals those rules and helps you apply them. Martin’s Clean Architecture doesn’t merely present options. Drawing on over a half-century of experience in software environments of every imaginable type, Martin tells you what choices to make and why they are critical to your success. As you’ve come to expect from Uncle Bob, this book is packed with direct, no-nonsense solutions for the real challenges you’ll face—the ones that will make or break your projects. Learn what software architects need to achieve—and core disciplines and practices for achieving it Master essential software design principles for addressing function, component separation, and data management See how programming paradigms impose discipline by restricting what developers can do Understand what’s critically important and what’s merely a “detail” Implement optimal, high-level structures for web, database, thick-client, console, and embedded applications Define appropriate boundaries and layers, and organize components and services See why designs and architectures go wrong, and how to prevent (or fix) these failures Clean Architecture is essential reading for every current or aspiring software architect, systems analyst, system designer, and software manager—and for every programmer who must execute someone else’s designs. Register your product at informit.com/register for convenient access to downloads, updates, and/or corrections as they become available.

作者简介:

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

书友短评:

@ DustinTang 最近第三遍细读了这本书,每一次都相对前一次有了更多的认识,应该是经历了更多项目经验的原因吧。简而言之,这本书是围绕着“细节”和“核心”的相对关系来阐述架构设计思想,核心原则是Dependency Rule——底层依赖高层,细节依赖核心,实现依赖抽象,变化依赖稳定。本书是一本“内功心法“而非“武功招式”,并不是一本教授如何做系统架构或者如何落地微服务的书,但作者多年深厚的经验在本书体现的淋漓尽致,读完之后真的有一种舒畅的感觉。作者在其系列书中分享的各种项目经验,在工作多年后真的非常有感触。很多的人可以成为好的程序员,但不一定是一名好的工程师 ——后者正是这本书想体现的思想。 @ 南阜鸟 结构性差了点 @ QZQ 这书没讲什么architecture

书籍目录

Foreword xv
Preface xix
Acknowledgments xxiii
About the Author xxv

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

  • 人渐渐地发现,这个世界上有很多问题就像翘翘板一样,只能要一边,这一边上去了,另边就下来了。就像要么用空间换时间,要么用时间换空间一样,你很难同时满足空间和时间要求的“双利解”;就像CAP的三选二的理论一样,这个世界不存在完美的解方案无论什么方案都有好的一面和不好的一面。而且这些工程师还还渐渐发现,每当引入一个新的技术来解決一个已有的问题时,这个新的技术就会带来更多的问题,问题就像有一个生命体一样,它们会不断地繁殖和进化。
    —— 引自章节:第1部分概述
  • 《架构整洁之道》孙宇聪译,软件架构参考书籍。第一章软件架构的终极目标是,用最小的人力成本来满足构建和维护该系统的需求。软件开发的核心特点:要想跑得快,先要跑得稳。过度自信只会使得重构设计陷入和原项目一样的困局中。研发团队最好的选择是清晰地认识并避开工程师们过度自信的特点,开始认真地对待自己的代码架构,对其质量负责。要想提高自己软件架构的质量,就需要先知道什么是优秀的软件架构。而为了在系统构建过程中采用好的设计和架构以便减少构建成本,提高生产力,又需要先了解系统架构的各种属性与成本和生产力的关系。第二章软件系统两个价值维度—–行为价值和架构价值。软件架构师这一职责本身就应该更关注系统的整体结构,而不是具体的功能和系统行为的实现。软件架构师必须创建出一个可以让功能实现起来更容易、修改起来更简单、扩展起来更轻松的软件架构。第四章在架构设计领域,功能性降解拆分仍然是最佳实践之一。第十五章软件架构师自身需要是程序员,并且必须一起坚持做一线程序员,绝对不要听从那些说应该让软件架构师从代码中解放出来以专心解决高阶问题的伪建议。如果不亲身承受因系统设计而带来的麻烦,就体会不到设计不佳所带来的痛苦,接着就会逐渐迷失正确的设计方向。软件架构这项工作的实质就是规划如何将系统切分成组件,并安排好组件之间的排列关系,以及组件之间互相通信的方式。软件架构的终极目标就是最大化程序员的生产力,同时最小化系统的总运营成本。在真正制作出来一个可复用框架之前,是不知道怎么制作一个可复用框架的。想要制作一个可复用的框架,必须要和几个复用该框架的应用一直开发。
    —— 引自第1页
  • 添加微信公众号:好书天下获取

    添加微信公众号:“好书天下”获取书籍好书天下 » Clean Architecture
    分享到: 更多 (0)

    评论 抢沙发

    评论前必须登录!

     

    添加微信公众号:“好书天下”获取书籍

    好书天下