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

82人评价

5星

54.9%
4星

34.1%
3星

9.8%
2星

0.0%
1星

1.2%

评价:

内容简介 · · · · · ·

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
· · · · · · (更多)

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

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

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

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

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

24.99元

: 微服务设计

29.99元

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

: Designing Data-Intensive Applicati...

: BDD in Action

: A Philosophy of Software Design

: Programming on Purpose

: Clean Code

: The Clean Coder

: Web API的设计与开发

: Release It!

: Reactive Design Patterns

: Web Development with Clojure

我来说两句

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

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

什么是话题

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

我要写书评

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

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

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

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

1 2回应

非洲酋长 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回应

Ajxxz 2018-11-29 07:41:52

Dependency Inversion

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

0回应

> 更多书评3篇

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