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
One of reading materials for OKR. Clean Embedded Architecture 那章直接跳过了，感觉相当一段时间我不会碰到那么底层的东西吧。整体感觉有些啰嗦，可以帮助新的senior engineer高屋建瓴地建构Architecture philosophy，Uncle Bob 对* is a Detail 部分讲的比较粗略，但我感觉这部分是很多五年经...One of reading materials for OKR. Clean Embedded Architecture 那章直接跳过了，感觉相当一段时间我不会碰到那么底层的东西吧。整体感觉有些啰嗦，可以帮助新的senior engineer高屋建瓴地建构Architecture philosophy，Uncle Bob 对* is a Detail 部分讲的比较粗略，但我感觉这部分是很多五年经验以下的工程师容易落入的陷阱。(展开)
One of reading materials for OKR. Clean Embedded Architecture 那章直接跳过了，感觉相当一段时间我不会碰到那么底层的东西吧。整体感觉有些啰嗦，可以帮助新的senior engineer高屋建瓴地建构Architecture philosophy，Uncle Bob 对* is a Detail 部分讲的比较粗略，但我感觉这部分是很多五年经...One of reading materials for OKR. Clean Embedded Architecture 那章直接跳过了，感觉相当一段时间我不会碰到那么底层的东西吧。整体感觉有些啰嗦，可以帮助新的senior engineer高屋建瓴地建构Architecture philosophy，Uncle Bob 对* is a Detail 部分讲的比较粗略，但我感觉这部分是很多五年经验以下的工程师容易落入的陷阱。(展开)
最初在网店发现这本书时，一看到书名我就很开心：Uncle Bob 出新书啦。扫了一眼目录，又心生疑惑：全书分为6个部分，第3个部分才讲到 SOLID 原则。这些原则在他的巨著《敏捷软件开发：原则、模式与实践》里已经花大量篇幅讲解了。莫不成连 Uncle Bob 也炒起冷饭了？ （没错，上...
(展开)
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
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
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
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
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
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
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
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版
Ajxxz
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 有用 ZjU3MmVmYmZiO 2019-10-27
Clean Architecture的图是很简单，但是得到这张图以及应用这张图就很难了。Draw boundary这种事情需要人有足够的经验的才行，否则画不好就悲剧了。Clean Architecture有点像高内聚低耦合，domain为内，infrastructure为外。
0 有用 逆铭睡眼惺忪地 2018-06-07
SOLID原则在架构层面的应用。有些有意思的地方，但实在嫌啰嗦，信噪比不高。同时有些例子细节上也confusing。
3 有用 [已注销] 2017-11-13
Bob大叔最新作，Bob一出，必属精品。软件架构师必读！
0 有用 盗火者Howell 2020-01-05
One of reading materials for OKR. Clean Embedded Architecture 那章直接跳过了，感觉相当一段时间我不会碰到那么底层的东西吧。整体感觉有些啰嗦，可以帮助新的senior engineer高屋建瓴地建构Architecture philosophy，Uncle Bob 对* is a Detail 部分讲的比较粗略，但我感觉这部分是很多五年经... One of reading materials for OKR. Clean Embedded Architecture 那章直接跳过了，感觉相当一段时间我不会碰到那么底层的东西吧。整体感觉有些啰嗦，可以帮助新的senior engineer高屋建瓴地建构Architecture philosophy，Uncle Bob 对* is a Detail 部分讲的比较粗略，但我感觉这部分是很多五年经验以下的工程师容易落入的陷阱。 (展开)
0 有用 沈小黑 2018-02-20
懵懵懂懂，再读一遍
0 有用 乌贼坊主 2020-05-09
醍醐灌顶，简直打通任督二脉：Structural/OO/Functional Programming的本质；Interface inverts dependency; Main is a plugin; Architecture is not framework.
0 有用 w28l30 2020-04-20
4.5，架构最重要的其实就是ETC(Easy to Change). 因为你永远无法知道需求会怎样变化。
0 有用 Liutos 2020-03-08
作者从入门的软件架构规则入手，逐个讲解剖析，然后抛出了插件式架构，真是让人心悦诚服，读起来简直不要太过瘾。
0 有用 阿叶 2020-01-21
电子书；网盘；架构与设计；
0 有用 盗火者Howell 2020-01-05
One of reading materials for OKR. Clean Embedded Architecture 那章直接跳过了，感觉相当一段时间我不会碰到那么底层的东西吧。整体感觉有些啰嗦，可以帮助新的senior engineer高屋建瓴地建构Architecture philosophy，Uncle Bob 对* is a Detail 部分讲的比较粗略，但我感觉这部分是很多五年经... One of reading materials for OKR. Clean Embedded Architecture 那章直接跳过了，感觉相当一段时间我不会碰到那么底层的东西吧。整体感觉有些啰嗦，可以帮助新的senior engineer高屋建瓴地建构Architecture philosophy，Uncle Bob 对* is a Detail 部分讲的比较粗略，但我感觉这部分是很多五年经验以下的工程师容易落入的陷阱。 (展开)