架构整洁之道读后感锦集

《架构整洁之道》是一本由【美】Robert C. Martin（罗伯特 C. 马丁）著作，电子工业出版社出版的平装图书，本书定价：99.00元，页数：348，特精心收集的读后感，希望对大家能有帮助。

　　《架构整洁之道》精选点评：

●这本架构相关的算是代码整洁之道的姐妹篇，理论偏多，需要时间消化，相对来说比较抽象吧

●控制反转、控制反转、以及为啥一个叫Robert C Martin的人老被人叫Bob大叔？

●一个月断断续续的把这本书看完了，前半部分感觉很受启发，后半部分没怎么理解。还需要多实践。准备写个读书笔记，再总结一下。

●非常好，但例子略少。用过DDD的可能读这本书感觉有重复

●不是老板，也不是架构师，所以没啥感觉。最后还是要回到场景和细节，运用之妙，存乎一心，并没有捷径可走。

●不错，虽然是很常见的套路，但是结尾的历史，更引人注意。

●算是架构入门的基础书籍吧…

●按照寻求《编程细节的最佳实践》的心态去看这本书，会很有收获。

●忘记了，只记得写了很多软件架构的很对建议

●可以作为设计模式的理论基础阅读，同套思想在不同层面的最佳实践。

《架构整洁之道》读后感(一)：经典好书

常看常新的经典架构书籍，对好的架构作出最本质的定义，通过组织结构最小化开发成本和演进成本。

结合bob大叔的经验，通篇讲怎么让架构达到高内聚低耦合。

因为本书自带clean标签，所以经历过多年项目架构设计毒打、看过架构随着代码演进而腐化的人才能理解本书的例子和经验

另外，ddd领域建模和整洁架构的图，配合起来真是天作之合

《架构整洁之道》读后感(二)：带给思考的架构书

从代码整洁之道到架构整洁之道，都有幸拜读。不同阶段阅读的收获不尽相同。

架构整洁之道总体来说还是写的比较通俗易懂，也是工作之余一周翻了个遍，同时也对自己这段时间自己在架构方面的一个总结，算一一映射自己在做架构时候的抉择。很多东西说不出个所以然，但是Bob大叔给出了答案。

对于新手同学这本书并不是很适合，不是说语言晦涩，而是没有经历过“本以为别人代码是一坨屎，结果冲掉厕所塌了”的话，很难体会到代码整洁、架构整洁的内涵。

这本书时不时还会继续翻翻，老外牛逼的地方在于归纳总结，这个可以帮助自己日常装逼

《架构整洁之道》读后感(三)：作者的几个观点

uncle bob作为有50年开发经验的程序员，以下1，2，4观点可用于回答一些常见的问题。3对常见编程范式的总结很精辟

1，设计design和架构architecture没有区别，底层设计细节和高层架构信息是不可分割的，他们组合在一起，共同定义了整个软件系统

2，行为价值和架构价值，架构价值是真正重要的事情。平衡系统架构的重要性和功能的紧急程度这件事，是软件研发人员的职责

3，结构化编程pp对程序控制权的直接转移进行了限制和规范；面向对象编程oop对程序控制权的间接转移进行了限制和规范；函数式编程fp对程序中的赋值进行了限制和规范（对并发很关键）

4，软件架构师自身需要是程序员，并且必须一直坚持做一线程序员。如果不亲身承受因系统设计而带来的麻烦，就不会体会到设计不佳带来的痛苦，接着就会逐渐迷失正确的设计方向

其他的，设计原则，组件构建原则，软件架构，实现细节，在《敏捷软件开发 : 原则、模式与实践》很中很多都有提及，跟《领域驱动设计》书的思想很多重合的地方。

《架构整洁之道》读后感(四)：书是好书，Uncle 还是那个 Uncle

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

（没错，上句话是典型的欲扬先抑反问句~ 接下来我要开始夸了~）

拿到书已经是春节长假的尾巴了，连着几天读完后不由得感叹：Uncle 还是那个 Uncle，真是一本好书。

首先说说让我疑惑的“炒冷饭”问题。全书324页，其中只有30页是讲 SOLID 原则的，每个原则只用寥寥几页就介绍完了。介绍的目的也是为了给主旨做铺垫。

书的前80页介绍了一些基础知识，比如三种编程范式（结构化编程、面向对象编程、函数式编程）和 SOLID（SRP、OCP、LSP、ISP、DIP）。即便熟悉作者的其他作品，也能从中得到一些新启发。比如作者对三种编程范式的一句话归纳分别是这样的：

并总结：

乍一看，不知所云。但紧接着作者用仅仅26页就把道理明明白白的摆了出来。

这之后，就是那30页的 SOLID 原则了，与《敏捷软件开发》一书不同，这次每个原则的示例更加简练。不论是自己琢磨，还是向人布道，都很合适。

读完这80页不禁赞叹：Uncle Bob 以理服人的功力越发深厚了。佩服佩服。

在剩余篇章里，作者讲解了如何通过管理依赖关系、剖析划分边界、分离业务逻辑与实现细节等方法设计出整洁的架构。（当然，这其中也包含了对著名的 Clean Architecture 的讲解 :-) ）

在书的尾声部分，作者强调了“数据库只是实现细节”、“Web 是实现细节”、“应用程序框架是实现细节”，这些都不是架构设计的核心。

而由 Simon Brown 撰写的第34章“拾遗”，则讲解了不同封装模式（按层封装、按功能封装、按端口和适配器封装、按组件封装）的异同以及封装与组织形式的区别。也是不可多得的好内容。

这本书适合有几年开发经验、不满足于平铺直述”码“代码、追求整洁设计的研发工程师。当然，也适合喜欢 Uncle Bob 作品的同好。

需要多啰嗦一句：Uncle Bob 是一位有数十年从业经验的资深工程师，书中有一些概念（如领域、业务实体、SOLID）在他是信手拈来，但部分读者可能会感到陌生。对于这些朋友，我推荐两本书：《领域驱动设计》和《敏捷软件开发：原则、模式与实践》。

另，在写这篇书评的时候，我无意间发现很久以前摘录的一段关于架构设计的话，分享给大家：

《架构整洁之道》读后感(五)：接口是依赖倒置的手段

作为一个老程序员，无论接口也好，依赖倒置也好，觉得自己特别的“懂”。但是站在架构的角度为什么这么做，这本书回答的很清楚。 书很薄，也容易读，周五下午书到家，周六下午读完了，整个周日都在思考接口和依赖倒置。

这本书还有个好处就是清晰的告诉你编程范式就三种：结构式，函数式和面向对象。你不知道我读完这个有多放松。好比你苦苦追剧38集，就等40集的真相大白，结果无意中听到了剧透。去的，这不是吊胃口么，老子不跟了。Bob就是这个剧透。

看完还有个思考是，按照Clean Architecture的设计，似乎有个假定业务是稳定的，我们外围的Application Logic，Presentation Layer，Runtime Environment在类似于Onion的结构外层。其实现实却不然，只要稍有维护经验的人都知道，简单的业务需求修改就可以跨越这些层。比如一个业务是新增业务，需要Entity做支撑，需要有着自己的业务逻辑和显示逻辑，包括可能需要Environment的Setup。简单说业务经常变，是不是Clean Architecture就不适用了？

是，也不是。如果业务一直变的情况下，而且不能预测方向的情况下我们该怎么做？我觉得有两点我们可以做：

* 注重模块化，谨慎抽象。给后期做一些准备。 * 通过使用接口，让有些依赖反转，目的是推迟做决定。

业务一直变，程序员/架构师有办法吗？坦白讲：没有。作为程序员/架构师我们能做些什么来改善吗？能。

BUT, WHAT IS COST OF DIP？

在几天的思考里还有个问题一直萦绕在我脑海里：DIP的代价是什么？如果没有代价的话，我们可以随意的用DIP原则。再说没有什么事情是没有代价的。 不知道你们有没有见到这样的项目：不管什么需求，都先要去定义和实现接口，实现和接口在接口被定义在不同的项目(部署单元)里。如果你是类似.NET和Java工程师，你肯定会见到这样的项目。这样的项目开发体验如何？

我有很多次遇到这样的项目的经历，开发和维护体验其实都及其糟糕，感觉不到任何DIP的好处，而是一堆神烦的约定。一个站在用例角度上的小修改，跨越好几个部署单元(DLL或者jar)。

调试的时候更加让人苦恼，你无法通过反馈的问题/日志，直接通过查阅代码来预测代码的运行行为。你对着报错却“迟迟”找不到原因。报错点和实际问题点隔上好远。每次项目里的小问题，都是对项目的一次大探索。

所以应用DIP的代价是什么？软件架构最重要的事情是什么？管理复杂度(Complexity Management)。减少不必要的意外复杂度(Accidental Complexity)。简单讲就是让本来的简单的事情保持简单。而DIP在引入隔离，推迟决定的同时也引入了复杂度： the DIP comes with the complexity.

关键点是：DIP这里引入的是必要的复杂度，还是意外的复杂度。

给那些“尽信书”的朋友：https://naildrivin5.com/blog/2019/12/02/dependency-inversion-principle-is-a-tradeoff.html

但是不妨碍，我给这本书5星。