作者:
Robert C. Martin 出版社: Prentice Hall 副标题: A Craftsman's Guide to Software Structure and Design 出版年: 2017-9-20 页数: 432 定价: USD 34.99 装帧: Paperback ISBN: 9780134494166
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 (“...
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 技术负责人。
目录
· · · · · ·
Foreword xv
Preface xix
Acknowledgments xxiii
About the Author xxv
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 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 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 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
最初在网店发现这本书时，一看到书名我就很开心：Uncle Bob 出新书啦。扫了一眼目录，又心生疑惑：全书分为6个部分，第3个部分才讲到 SOLID 原则。这些原则在他的巨著《敏捷软件开发：原则、模式与实践》里已经花大量篇幅讲解了。莫不成连 Uncle Bob 也炒起冷饭了？ （没错，上...
(展开)
When software is done right, it requires a fraction of the human resources to create and maintain. Changes are simple and rapid. Defects are few and far between. Effort is minimized, and functionality and flexibility are maximized. The goal of software arch...
(展开)
Think of Main as a plugin to the application -- a plugin that sets up the initial conditions and configurations, gathers all the outside resources, and then hands control over to the high-level policy of the applicaiton. Since it is a plugin, it is possible to have many Main components one for each configuration of your application. For example, you could have a Main plugin for Dev, anothoer fo...
2018-01-06 18:15:30
Think of Main as a plugin to the application -- a plugin that sets up the initial conditions and configurations, gathers all the outside resources, and then hands control over to the high-level policy of the applicaiton. Since it is a plugin, it is possible to have many Main components one for each configuration of your application.
For example, you could have a Main plugin for Dev, anothoer for Test, and yet another for Production. You could also have a Main plugin for each country you deploy to, or each jurisdiction, or each customer.
When you think about Main as a plugin component, sitting behind an architectural boundary, the problem of configuration becomes a lot easier to solve.
The way to accomplish this goal is to create a specific API that the tests can use to verify all the business rules. This API should have superpowers that allow the tests to avoid security constraints, bypass expensive resources (such as databases), and force the system into particular testable states. This API will be a superset of the suite of interactors and interface adapters that are used ...
2018-01-06 18:24:49
The way to accomplish this goal is to create a specific API that the tests can use to verify all the business rules. This API should have superpowers that allow the tests to avoid security constraints, bypass expensive resources (such as databases), and force the system into particular testable states. This API will be a superset of the suite of interactors and interface adapters that are used by the user inerface.
The Purpose of the testing API is to decouple the tests from the application. This decoupling encompasses more than just detaching the tests from the UI: The goal is to decouple the structure of the tests from the structure of the application.
The superpowers of the testing API could be dangerous if they were deployed in production systems. If this is a concern, then the testing API, and the dangerous parts of its implemtation should be kept in a separate, independently deployable component.
The code they produce may not be pretty; but it works. It works because getting something to work -- once -- just isn't that hard. Getting software right is hard.
2018-01-06 16:40:24
The code they produce may not be pretty; but it works. It works because getting something to work -- once -- just isn't that hard.
These developers buy into a familiar lie: "We can clean it up later; we just have to get to market first!" Of course, things never do get cleaned up later, because market pressures never abate.Their overconfidence will drive the redesign into the same mess as the original project. The fact is that making messes is always slower than staying clean, no matter which time scale you are using. The o...
2018-01-06 16:44:48
These developers buy into a familiar lie: "We can clean it up later; we just have to get to market first!" Of course, things never do get cleaned up later, because market pressures never abate.Their overconfidence will drive the redesign into the same mess as the original project.
The fact is that making messes is always slower than staying clean, no matter which time scale you are using.
Every software system provides two different values to the stakeholders: behavior and structure. Software developers are responsible for ensuring that both those values remain high. Software must be soft -- that is, it must be easy to change. When the stakeholders change their minds about a feature, that change should be simple and easy to make. The difficulty in making such a change should be ...
2018-01-06 16:48:47
Every software system provides two different values to the stakeholders: behavior and structure. Software developers are responsible for ensuring that both those values remain high.
Software must be soft -- that is, it must be easy to change. When the stakeholders change their minds about a feature, that change should be simple and easy to make. The difficulty in making such a change should be proportional only to the scope of the change, and not to the shape of the change.
The way to accomplish this goal is to create a specific API that the tests can use to verify all the business rules. This API should have superpowers that allow the tests to avoid security constraints, bypass expensive resources (such as databases), and force the system into particular testable states. This API will be a superset of the suite of interactors and interface adapters that are used ...
2018-01-06 18:24:49
The way to accomplish this goal is to create a specific API that the tests can use to verify all the business rules. This API should have superpowers that allow the tests to avoid security constraints, bypass expensive resources (such as databases), and force the system into particular testable states. This API will be a superset of the suite of interactors and interface adapters that are used by the user inerface.
The Purpose of the testing API is to decouple the tests from the application. This decoupling encompasses more than just detaching the tests from the UI: The goal is to decouple the structure of the tests from the structure of the application.
The superpowers of the testing API could be dangerous if they were deployed in production systems. If this is a concern, then the testing API, and the dangerous parts of its implemtation should be kept in a separate, independently deployable component.
Think of Main as a plugin to the application -- a plugin that sets up the initial conditions and configurations, gathers all the outside resources, and then hands control over to the high-level policy of the applicaiton. Since it is a plugin, it is possible to have many Main components one for each configuration of your application. For example, you could have a Main plugin for Dev, anothoer fo...
2018-01-06 18:15:30
Think of Main as a plugin to the application -- a plugin that sets up the initial conditions and configurations, gathers all the outside resources, and then hands control over to the high-level policy of the applicaiton. Since it is a plugin, it is possible to have many Main components one for each configuration of your application.
For example, you could have a Main plugin for Dev, anothoer for Test, and yet another for Production. You could also have a Main plugin for each country you deploy to, or each jurisdiction, or each customer.
When you think about Main as a plugin component, sitting behind an architectural boundary, the problem of configuration becomes a lot easier to solve.
Marquezzzzz
电子工业出版社2018版
boxcounter
电子工业出版社2018版
清风乱醉
电子工业出版社2018版
张少华
电子工业出版社2018版
ax_
麦机长
电子工业出版社2018版
Aquietzero
Think of Main as a plugin to the application -- a plugin that sets up the initial conditions and configurations, gathers all the outside resources, and then hands control over to the high-level policy of the applicaiton. Since it is a plugin, it is possible to have many Main components one for each configuration of your application. For example, you could have a Main plugin for Dev, anothoer fo...
0 有用 阿叶 2020-01-21 15:18:16
电子书；网盘；架构与设计；
0 有用 绿袜子 2020-07-15 07:06:33
前半本Programming Paradigms和Design Principles讲得很不错 后半本不知道在干嘛
0 有用 martonyong 2019-09-04 01:31:34
介绍了一些概念，让你对架构大体有了一些了解。需要更多的实践和学习才能更进一步。
0 有用 ZjU3MmVmYmZiO 2019-10-27 16:19:31
Clean Architecture的图是很简单，但是得到这张图以及应用这张图就很难了。Draw boundary这种事情需要人有足够的经验的才行，否则画不好就悲剧了。Clean Architecture有点像高内聚低耦合，domain为内，infrastructure为外。
3 有用 Pumpkin_Snail 2018-01-04 18:20:26
对于想要在程序设计上更进一步的程序员，这本书像是一个引子
0 有用 哈斯达根 2022-03-27 17:32:31
系统地学习了 clean architecture很有必要。终于弄清楚了啥是 business logic。
0 有用 Albert 2021-12-19 14:09:02
看了一个半月你总算看完了，确实启发很大
0 有用 Z 2021-08-18 14:31:54
高屋建瓴。
0 有用 ln330640653 2021-07-22 23:54:47
1. don't depend on what you don't need 2. depend on abstraction,not concrete implemention 3. low-level details depend on high-level policies
0 有用 Yuki 2021-06-06 20:23:34
interface yyds