Name: Clean Architecture
ISBN: 9780134494166

作者: [美] Robert C·Martin
出版社: Prentice Hall
副标题: A Craftsman's Guide to Software Structure and Design
出版年: 2017-9-20
页数: 432
定价: USD 34.99
装帧: Paperback
ISBN: 9780134494166

豆瓣评分

8.7

92人评价

5星

52.2%
4星

34.8%
3星

12.0%
2星

0.0%
1星

1.1%

评价:

内容简介 · · · · · ·

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 (“...

(展开全部)

作者简介 · · · · · ·

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

Part I: Introduction 1
· · · · · · (更多)

豆瓣成员常用的标签(共51个) · · · · · ·

架构计算机 Architecture 软件开发软件工程编程程序设计 programming

喜欢读"Clean Architecture"的人也喜欢的电子书 · · · · · ·

支持 Web、iPhone、iPad、Android 阅读器

: 代码之外的功夫：程序员精进之路

24.99元

: 微服务设计

29.99元

喜欢读"Clean Architecture"的人也喜欢 · · · · · ·

: Designing Data-Intensive Applicati...

: A Philosophy of Software Design

: Java 9 Modularity

: BDD in Action

: Practical Unit Testing with JUnit an...

: Programming on Purpose

: Clean Code

: The Nature of Software Developme...

: Building Evolutionary Architectures

: The Clean Coder

我来说两句

短评 · · · · · · ( 全部 36 条 )

Clean Architecture的话题 · · · · · · ( 全部条 )

什么是话题

无论是一部作品、一个人，还是一件事，都往往可以衍生出许多不同的话题。将这些话题细分出来，分别进行讨论，会有更多收获。

我要写书评

Clean Architecture的书评 · · · · · · ( 全部 8 条 )

勿忘初心架构就解决业务问题的

这篇书评可能有关键情节透露

2018年读的第一本书，这个是clean code 之后又一个佳作。另， Bob 大叔是将故事的好手，本书章节都蛮短，但是有力。故事是从一个例子开始，为什么软件生产效率为什么会下降？是什么原因导致的下降？软件的外部质量（behavior）和内部质量（code/structure）。当只关注软件... (展开)

1 2回应

Marquezzzzz 2019-02-03 21:28:11 电子工业出版社2018版

所阅读的最好的关于架构的书

这篇书评可能有关键情节透露

之前一直在找关于架构的书和文章，无奈市面上关于架构的书质量太差，关于架构的文章又太过细节，并且架构是什么这个问题大家一直存在争议。直到看到Uncle Bob的这本书，才对架构有了一个清晰的认识。不得不感叹，毕竟Bob大叔是写过五十年代码的人啊～～简单做一下笔记和自己提... (展开)

0回应

Ajxxz 2018-11-29 07:41:52

Dependency Inversion

重提了一遍各种principles。SOLID中S和D的思想贯穿整本书。收获最大的还是D，Dependecy Invsrsion。通过interface（或者说Polymorphism），使得在boundary crossing的时候，“底层”指向“高层”。感觉是从另外一个角度去看待interface如何解耦合。 (展开)

0回应

william 2018-10-31 20:58:17

很有启发

看了youtube上bob大叔在yale的演讲，和想象中的标准闷骚码农不同，bob叔是个很风趣的人，还有点毒舌，哈哈，内容大体就是这本书前几章的内容链接：https://www.youtube.com/watch?v=TMuno5RZNeE&t=2880s 很多之前困惑不已的问题都清晰起来： Rigidity: What is bad code:... (展开)

0回应

虾卤 2019-03-18 17:30:24

分章节读后总结

这篇书评可能有关键情节透露

因为看的比较早，读的英文版，又因为读英文版不熟练，将各章节重点总结下第一章通过反例，强调了一个良好设计的软件架构的重要性。第二章功能与架构，哪个更重要？核心在于聚焦于重要的事情，不要将 "紧急不重要" 错当成 "紧急重要"。第三&四&五&六章探讨了3... (展开)

0回应

boxcounter 2019-02-12 18:23:17 电子工业出版社2018版

书是好书，Uncle 还是那个 Uncle

最初在网店发现这本书时，一看到书名我就很开心：Uncle Bob 出新书啦。扫了一眼目录，又心生疑惑：全书分为6个部分，第3个部分才讲到 SOLID 原则。这些原则在他的巨著《敏捷软件开发：原则、模式与实践》里已经花大量篇幅讲解了。莫不成连 Uncle Bob 也炒起冷饭了？（没错，上... (展开)

0回应

Tigerhehe 2019-01-25 11:25:40

道

这是一本讲架构设计之道的书；道理，说简单也简单，就是根据功能的层次和依赖关系解耦合；说复杂也复杂，如何在架构理想和项目现实之间平衡，不是书本可以说清楚学得到的。知易行难是永远难以解决的问题。作为一个同在PDP11上写出Hello world的老工程师，我对Martin老师所述... (展开)

0回应

stallboy 2018-11-14 17:36:38 电子工业出版社2018版

作者的几个观点

uncle bob作为有50年开发经验的程序员，以下1，2，4观点可用于回答一些常见的问题。3对常见编程范式的总结很精辟 1，设计design和架构architecture没有区别，底层设计细节和高层架构信息是不可分割的，他们组合在一起，共同定义了整个软件系统 2，行为价值和架构价值，架构价值... (展开)

0回应

> 更多书评8篇

读书笔记 · · · · · · (共19篇)

我来写笔记

按有用程度
按页码先后
最新笔记

展开收起
第237页

两骖如舞

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.

推荐

回应 2018-01-06 18:15
展开收起
第252页

两骖如舞

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.

推荐

回应 2018-01-06 18:24
展开收起
第213页

两骖如舞

Nothing is left for the View to do other than to load the data from the View Model into the screen. Thus the View is humble.
2018-01-06 18:09

Nothing is left for the View to do other than to load the data from the View Model into the screen. Thus the View is humble.

推荐

回应 2018-01-06 18:09
展开收起
第197页

两骖如舞

Architectures are not (or should not be) about frameworks. Architectures should not be supplied by frameworks. Frameworks are options to be left open. Good architectures are centered on use cases so that architects can safely describe the structures that support those use cases without committing to frameworks, tools, and enviroments.
2018-01-06 18:06

Architectures are not (or should not be) about frameworks. Architectures should not be supplied by frameworks. Frameworks are options to be left open.
Good architectures are centered on use cases so that architects can safely describe the structures that support those use cases without committing to frameworks, tools, and enviroments.

推荐

回应 2018-01-06 18:06

展开收起
第1页

两骖如舞

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.
Getting software right is hard.

推荐

回应 2018-01-06 16:40
展开收起
第5页

两骖如舞

The goal of software architecture is to minimize the human resources required to build and maintain the required system.
2018-01-06 16:42

The goal of software architecture is to minimize the human resources required to build and maintain the required system.

推荐

回应 2018-01-06 16:42
展开收起
第10页

两骖如舞

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.
The only way to go fast, is to go well.

推荐

回应 2018-01-06 16:44
展开收起
第14页

两骖如舞

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.

推荐

回应 2018-01-06 16:48

展开收起
第252页

两骖如舞

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.

推荐

回应 2018-01-06 18:24
展开收起
第237页

两骖如舞

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.

推荐

回应 2018-01-06 18:15
展开收起
第213页

两骖如舞

Nothing is left for the View to do other than to load the data from the View Model into the screen. Thus the View is humble.
2018-01-06 18:09

Nothing is left for the View to do other than to load the data from the View Model into the screen. Thus the View is humble.

推荐

回应 2018-01-06 18:09
展开收起
第197页

两骖如舞

Architectures are not (or should not be) about frameworks. Architectures should not be supplied by frameworks. Frameworks are options to be left open. Good architectures are centered on use cases so that architects can safely describe the structures that support those use cases without committing to frameworks, tools, and enviroments.
2018-01-06 18:06

Architectures are not (or should not be) about frameworks. Architectures should not be supplied by frameworks. Frameworks are options to be left open.
Good architectures are centered on use cases so that architects can safely describe the structures that support those use cases without committing to frameworks, tools, and enviroments.

推荐

回应 2018-01-06 18:06