注册

下载豆瓣客户端

豆瓣 6.0 全新发布 ×

豆瓣

扫码直接下载

iPhone · Android

豆瓣读书

Clean Architecture

Clean Architecture

作者: [美] 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.6

65人评价

5星

53.8%
4星

35.4%
3星

9.2%
2星

0.0%
1星

1.5%

评价:

内容简介 · · · · · ·

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

目录 · · · · · ·

Foreword xv
Preface xix
Acknowledgments xxiii
About the Author xxv

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

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

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

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

: Designing Data-Intensive Applicati...

: BDD in Action

: A Philosophy of Software Design

: Programming on Purpose

: MongoDB Applied Design Patterns

: Web API的设计与开发

: Web Development with Clojure

: Clean Code

: Reactive Design Patterns

: Java应用架构设计

我来说两句

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

热门 / 最新 / 好友

2 有用奏乐 2018-02-21

读下SOLID原则和 clean arch那章就差不多可以了
0 有用黎明灰烬 2018-06-06

Which classes belong in which components? This is an important decision, and requires guidance from good software engineering principles. Unfortunately, over the years, this decision has been made in ... Which classes belong in which components? This is an important decision, and requires guidance from good software engineering principles. Unfortunately, over the years, this decision has been made in an ad hoc manner based almost entirely on context. (展开)
2 有用狂气之瞳改 2018-06-23

为扩展性而设计不过一句话：对稳定KISS，对易变抽象。设计之外，是更复杂的业务知识和os/db/web技术细节。读完很是伤感，半个世纪过去了，software design仍既不是science也不是common sense，只是读者们或仍能期待有生之年的下半个世纪。
0 有用 teoking 2018-03-15

很不错的架构类书籍。对软件架构的元素、方法等讲的很清楚。示例都比较简单。带一些软件变化历史的讲述，很开阔视野。总体评价很好。
0 有用 Roc 2018-01-03

uncle Bob 在clean code 之后又一大作

0 有用 A栋301 2018-09-23

这本书写的思想非常具有启发性，值得反复阅读
0 有用 realvalkyrie 2018-08-26

还是多经历些了痛点开始明白书中讲到的东西，架构设计的checklist和基本原则
1 有用胡皓 2018-07-29

对想要对如今的架构设计建立正确认知的人来说，这里有你需要的思想上的一切，对于想要知道细节的人来说，我只想说：对不起，要么你火候不够，要么你读错书了……
0 有用 [已注销] 2018-07-17

最近的架构设计里涉及到了IOC。重读大叔的书，依然收获丰富，解决了一个难题：）
0 有用 DustinTang 2018-07-11

老实讲, 不太系统...

> 更多短评 25 条

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

什么是话题

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

我要写书评

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

热门 / 最新 / 好友

Roc 2018-01-03 12:06:03

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

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

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

非洲酋长 2018-10-31 20:58:17

很有启发

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

> 更多书评2篇

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

我来写笔记

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

展开收起
第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

展开收起
第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

> 更多读书笔记（共19篇）

在这本书的论坛里发言

其他版本在豆瓣书店有售 · · · · · ·

在哪儿买这本书 · · · · · ·

+ 加入购书单

这本书的其他版本 · · · · · · ( 全部3 )

电子工业出版社版 2018-9 / 25人读过 / 有售
电子工业出版社版 2018-7 / 1人读过 / 有售

以下豆列推荐 · · · · · · ( 全部 )

书单 (lyb)
2018 Reading List (conndots)
Architecture (dhcn)
计算机 (Earth_melody)
技术类经典书籍存档 (ddlee)

谁读这本书?

11月16日想读

二手市场

> 点这儿转让有582人想读,手里有一本闲着?

订阅关于Clean Architecture的评论:
feed: rss 2.0