《架构整洁之道》是一本由【美】Robert C. Martin（罗伯特 C. 马丁）著作，电子工业出版社出版的平装图书，本书定价：99.00元，页数：348，特精心从网络上整理的一些读者的读后感，希望对大家能有帮助。
《架构整洁之道》精选点评：
●不错，虽然是很常见的套路，但是结尾的历史，更引人注意。
●比较理论化也没有什么独特的东西，理论结合实际解决问题才是最重要的，真正的架构是不断的权衡取舍和妥协积累出来的。
●看完以后心情久久不能平复。在实际的开发过程中，有那么多次的痛苦、心烦意乱、吐槽前人留下的代码。看了本书以后，才知道原来一个整洁的项目应该是什么样的、现有项目中有什么问题、未来应该怎么避免这些问题、哪些东西才是一个项目中重要的东西。感谢作者
●一段轻松、愉快的阅读历程。这书属于常看常新，而后融入自身，趋于平淡的类型。在“道法术器”划分中属于“法”这个范畴，书中的类容本身并不面向实操。 另，将书中的SOLID原则和组件聚合原则，与《写给大家看的设计书》提倡的设计的4大基本原则“对比、重复、对齐与亲密性”进行映射和类比，十分有趣，两个视觉下的“设计原则”有重叠也有互补。
●Bob大叔的书会为你提供原则，而不是规则。海纳百川，兼收并蓄。可以发现各种架构方法的特点、优点、局限。受益匪浅，相见恨晚！
●结合这些年做过的一些重构工作，读起来还是挺有感悟。SOLID的思想贯穿整本书，小到代码大到系统。 未来应该还会复读一遍。
●内容很好，结合代码就更好了
●感觉讲“ 从基础构件开始：编程范式”这部分最好，三个范式从不同维度增加编程的限制。
●这是一本架构框架类型的神叔，里面充满专业术语和幽默色彩，让人反思和顿然开悟的语句非常之多！推荐大家细细品尝！
●抽象能力才是一个架构师的基础
《架构整洁之道》读后感(一)：带给思考的架构书
从代码整洁之道到架构整洁之道，都有幸拜读。不同阶段阅读的收获不尽相同。
架构整洁之道总体来说还是写的比较通俗易懂，也是工作之余一周翻了个遍，同时也对自己这段时间自己在架构方面的一个总结，算一一映射自己在做架构时候的抉择。很多东西说不出个所以然，但是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）在他是信手拈来，但部分读者可能会感到陌生。对于这些朋友，我推荐两本书：《领域驱动设计》和《敏捷软件开发：原则、模式与实践》。
另，在写这篇书评的时候，我无意间发现很久以前摘录的一段关于架构设计的话，分享给大家：
在一个项目的整体结构之内，总有空间展示个性和匠心 …… 百年之后，我们的技艺或许如今日的土建工程师看到中世纪大教堂建造者使用的技法一样陈旧，但是我们的匠心会得到尊重。—— 据说出自《程序员修炼之道（The Pragmatic Programmer）》《架构整洁之道》读后感(四)：所阅读的最好的关于架构的书
之前一直在找关于架构的书和文章，无奈市面上关于架构的书质量太差，关于架构的文章又太过细节，并且架构是什么这个问题大家一直存在争议。直到看到Uncle Bob的这本书，才对架构有了一个清晰的认识。不得不感叹，毕竟Bob大叔是写过五十年代码的人啊～～
简单做一下笔记和自己提出的问题。
1.软件架构
软件架构的终极目标是，用最小的人力成本来满足构建和维护该系统的需求。tips 现实工作中，尤其是互联网公司中，追求快速的功能实现是非常常见的事情，但是这并不意味着我们可以放弃架构上的抗争。很多事情都是一种trade off。
设计软件架构的目的就是为了在工作中更好的对这些组件进行研发，部署，运行，维护tips 软件架构需要考虑现实，比如当下流行的微服务架构（如果能称其为架构的话）看起来非常美好，其实对运维的要求比较高，研发维护难度会提升。
如果想设计一个便于推进各项工作的系统，其策略就是要在设计中尽可能长时间保留尽可能多的可选项。tips 不过度设计，但是又为未来保留可选项。
一个良好的架构设计应该围绕着用例来展开，这样的架构设计可以在脱离框架、工具及其使用环境的情况下完整地描述用例。tips 嗯，毕竟业务才是核心
2.基础，三种编程范式，solid原则。
3.组件构建原则
rep 软件复用的最小粒度应等同于其发布的最小粒度 ccp 我们应该讲那些会同时修改，并且为相同目的而修改的类放到同一个组件中，而将不会同时修改，并且不会为了相同目的而修改的那些类放到不同的组件中crp 不要强迫一个组件的用户依赖他们不需要的东西无依赖环原则 组件依赖关系中不应该出现环稳定依赖原则 依赖关系必须要指向更稳定的方向稳定抽象原则 一个组件的抽象化程度应该与其稳定性保持一致4.业务才是最有价值的。
策略体现的是软件中所有业务规则和操作过程，因为它是系统真正的价值所在。tips 我们程序员经常犯的一个误区是重技术轻业务，出口必言具体技术，这是非常可怕的。通过架构层次的梳理，一下子就扭转了这种偏见。
5.顶层元素
应用，组件应该包含系统顶层元素，这些元素会以类，函数或模块的形式在架构中占据明显的位置，它们的名字也能够清晰描述对应的功能。tips 就是一眼就能看懂的意思啦。回想起我们公司项目的许多模块，我至今都不知道它到底想表达什么。里面没有顶层结构，更多地是各种杂物的堆砌。
6. 划分边界，确定层次
一条策略距离系统的输入／输出越远，它所属的层次就越高因为过度的工程设计往往比工程设计不足还要糟糕。但另一方面，如果我们发现自己在某个位置确实需要设置一个架构边界，却又没有事先准备的时候，再添加边界所需要的成本和风险往往是很高的。软件架构师必须仔细权衡成本，决定哪里需要设计架构边界，以及这些地方需要的是完整的边界，还是不完全的边界，还是可以忽略的边界。tips 不设置边界会有什么问题呢？
7.整洁架构
跨边界传输的对象应该有一个独立、简单的数据结构。总之不能投机取巧地直接传递业务实体或者数据库对象记录。
8.main方法是一种组件，测试也是一种组件
所有的初始化组件都是细节
9.服务化并没有解耦
非常欣赏Bob大叔对当前流行的服务化或者微服务的一些观点，这些不能称之为架构，哈哈哈～～
10.数据库是细节，web是细节，框架是细节
原来所有的数据表驱动设计的根源是因为磁盘的数据存储格式，这样就非常尴尬了，程序员还是喜欢各种不同种类的数据结构
尽量不要依赖框架，甚至是spring
11.拾遗
设计一定要落地，映射到对应的代码结构上，耦合模式上。保持开放，但一定要务实，同时要考虑到团队的大小，技术水平，以及对应的时间和预算限制。tips 说得很好，我们在现实工作中总会遇到各种各样的限制～～
《架构整洁之道》读后感(五)：架构师的入门书
组件的核心依赖关系这本书是 Bob 大叔的架构设计入门之书，提供了一些通用的设计原则，明确了工程师的责任，也批评一些错误的观念，例如
为设计良好的架构而斗争，如果系统越来越难以维护，最终无法修改。或者靠大量人力修复无止尽的 bug，这说明架构师没有与需求方做足够的抗争，没有完成自己应尽的职责。
按照正确的方式做事儿并不比匆忙地做事儿慢
拆分成微服务，使用了消息通信并不代表你的系统解耦了
架构的核心是 use case 和 依赖于 use case 的合理边界与依赖关系的设计，而非关注那些细节
极力推荐阅读，尤其是有一定工作经验，并且想成为架构师，尤其是业务架构师的工程师阅读。 下文是一些比较详细的笔记，为什么要设计良好的架构 架构的设计目标是以最小的人力来构建和维护系统 工程师一般都会过于自信，而且不会偷懒工作。真正偷懒的地方是持续低估那些优秀的良好设计代码和架构的重要性 无论是长期还是短期，胡乱设计的代码和架构的工作速度其实比用正确的方式更慢 唯一可以使工作变快的方法是使用正确的方式做事 为设计良好的架构而斗争，如果系统越来越难以维护，最终无法修改。或者靠大量人力修复无止尽的 bug，这说明架构师没有与需求方做足够的抗争，没有完成自己应尽的职责。 编程范式 编程范式都是从某一方面限制和规范了程序员的能力，没有增加新的能力的。目的是为了设置限制。告诉我们不能做什么，而不是刻意做什么 结构化编程对程序控制权的直接转移进行了限制和规范 goto 语句的某些用法会导致某个模块无法被拆分成更小的，可证明的单元。 结构化编程促使我们将程序递归降解成一系列可证明的小函数，然后编写测试证明这些函数是错误的，如果无法证伪，就推导出来整个程序是对的 功能性降解拆分是架构领域最佳实践之一 架构师需要定义容易证伪的模块，组件以及服务 面向对象编程对程序控制权的间接转移做了限制和规范 面向对象语言的多态取代了使用函数指针时这些人工遵守的约定，消除了这方面的危险。 架构师构建插件式架构，让高层策略性组件与底层实现组件分离，底层组件可以编译成插件，实现独立于高层组件的开发和部署 函数式编程对于程序中的赋值进行了限制和规范 一个架构设计良好的程序应该将状态修改的部分和不需要修改的部分隔离成单独的组件，然后用合适的机制保护可变量 架构师应当着力于将大部分逻辑归属于不可变组件中，可变组件的逻辑越少越好 现有的代码管理程序使用的是 Event Sourcing 架构 设计原则（SOLID） 单一职责（SRP）: 一个软件系统的最佳结构依赖于开这个系统的组织的内部结构，这样每个软件有且只有一个被修改的理由（业务维度） 任何一个软件模块都应该只对某一类行为负责 开闭原则（OCP）: 如果系统想要容易被改变，那么其设计就必须允许只靠增加代码来改变系统行为，而非只能修改原有代码 里氏替换原则（LSP）：使用遵同一约定的可替换的组件构建系统 接口隔离原则（ISP）：架构设计中一定要减少不必要的依赖 任何层次的软件设计如果依赖了并不需要的东西，就会带来意料之外的麻烦 依赖翻转原则（DIP）：高层策略性代码不应该底层细节代码，底层细节代码应该依赖策略性代码 组件构建原则 组件聚合 The Reuse/Release Equivalence Principle（REP） 组件中的类和模块必须是彼此紧密相关的，一个组件不能由一组毫无关联的类和模块组成，他们之间应该有一个共同的主题 软件复用的最小粒度应该等同于其发布的最小粒度 THE COMMON CLOSURE PRINCIPLE（CCP） 将由于相同原因，相同目的修改的东西放在一起。将不同的分开。 Common Reuse Principle（CRP） 不要让用户依赖不需要用到的东西 组件耦合 无环依赖原则，使用接口，依赖翻转解决循环依赖问题 自上而下的设计，隔离频繁的变更 组件依赖关系一定要随着业务逻辑的变化而演进 依赖关系必须指向更稳定的方向 让组件难以修改的最直接方法就是让很多组件依赖它 一个组件的抽象程度应该与它的稳定性保持一致 软件架构什么是软件架构架构师应该是能力最强的一群程序员，不仅需要自己承接编程任务，也需要引导整个团队向一个能够最大化生产力的系统设计方向前进。架构师的代码量不是最多的，但是必须持续写代码，这样才能不断体会设计不佳所带来的痛苦。 如果想设计一个便于推进各项工作的系统，策略就是要在设计中尽可能长时间地保留更多的可选项。架构的终极目标就是最大化程序员的生产力，同时最小化系统的运营成本架构设计需要考虑到的角度，开发，部署，运行，维护，保持可选项开发高层策略时摆脱具体细节的纠缠，在后期我们就有更多的信息来做出合理选择一个优秀的架构师应该致力于最大化可选项的数量，细节的决策要越晚做越好独立性一个良好的架构，必须支持以下几点业务系统用例的正常运行系统的运行维护系统的开发任何一个组织在设计系统时，往往都会复制出一个与该组织内沟通结构相同的系统系统的部署如果有两段看起来重复的代码，如果他们有些不同的变更速率或者缘由，那么这两块代码就不是真正的重复解耦的集中类型，源码层次，部署层次，服务层次建议系统的解耦程度到一旦有需要就会比较轻易地转化成独立部署的服务即可，让整个程序长期保持单体结构，以便给未来留下可选项划分边界架构师追求的是最大限度的降低构建和维护一个系统所需要的人力，其中最消耗人力资源的是系统中的耦合，尤其是那些过早做出来的，不成熟的决策所导致的耦合将系统划分为系统核心组件与核心业务逻辑无关但是负责提供必要功能的组件，让这些非核心组件依赖核心业务逻辑组件，这是依赖反转（DIP）和稳定抽象（SAP）的具体应用。尖叫的软件架构良好的架构设计应该只关注用例，并且能将他们与周边的因素隔离新来的程序员能第一步需要了解的是业务用例，项目中要能明确的体现业务逻辑的逻辑，而非使用的框架和交付方式展示期与兼备对象 谦卑对象模式最初的设计目的是帮助单元测试编写者区分容易测试与难以测试的行为 谦卑是拟人化的，指难以测试的对象清晰地认识到自己的局限性，只发挥自己桥梁与通信的作用，并不从中干预信息传输 层次与边界 不将未来的需求抽象化，「You aren’t going to need it」，一项中的需求往往是不存在的 需要发现在某个位置确实需要边界，如果不设置，再添加的时候需要的成本和风险往往是比较高的 架构师需要在上边两点做 trade-off，需要一点点未卜先知的能力 服务：宏观与微观 架构设计的任务就是找到高层策略与底层细节之间的架构边界，同时保证这些边界遵守依赖关系规则。至于是服务调用还是函数调用，只是应用程序的一种切分方式，与系统架构无关 拆分成服务通信，拆分成消息通信并不意味着服务可以独立开发，部署，运维。这点儿需要尤其注意 横跨性变更问题（类似于不合理的水平拆分）时所有系统都要面对的问题，它会造成系统特别脆弱，无论是服务化的还是非服务化的。 实现细节 数据库只是实现细节 应用框架是实现细节 Web 只是实现细节
扫一扫手机访问
