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

96人评价

5星

51.0%
4星

36.5%
3星

11.5%
2星

0.0%
1星

1.0%

评价:

内容简介 · · · · · ·

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

: The Clean Coder

: Building Evolutionary Architectures

我来说两句

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

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

什么是话题

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

我要写书评

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

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

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

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

1 2回应

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回应

Tigerhehe 2019-01-25 11:25:40

道

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

0回应

> 更多书评5篇

读书笔记 · · · · · · (共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