书籍介绍
这本书最戳中工程师的地方，或许不是它给了你一套架构法则，而是它无情地揭示了一个反复上演的陷阱：'我们可以以后再重构'——于是重构永远不再发生，系统最终沦为没人敢动的乱麻。作者以半个世纪的工程经验，反复强调架构师必须留在一线写代码，因为不亲身承受设计糟糕带来的痛苦，就永远找不到正确的设计方向。它反复讲'为什么'而非'怎么做'：对稳定部分用KISS，对易变部分用抽象，让低层依赖高层而非相反。但正因为它提纲挈领、刻意略浅，也招致'不够系统'的争议。因此它更适合有一定工程经验、能读懂其中血泪教训的读者，而非初学者的操作手册。
AI导读
核心看点
- 强调业务逻辑独立于框架、数据库和UI
- 依赖倒置原则在架构层面的核心应用
- 架构师需坚持一线编程以体会设计痛点
读者共识
- 观点深刻但部分章节略显啰嗦
- 是理解整洁架构的入门经典之作
- 需有项目踩坑经验方能深刻共鸣
精彩摘录
- "人渐渐地发现，这个世界上有很多问题就像翘翘板一样，只能要一边，这一边上去了，另边就下来了。就像要么用空间换时间，要么用时间换空间一样，你很难同时满足空间和时间要求的“双利解”；就像CAP的三选二的理论一样，这个世界不存在完美的解方案无论什么方案都有好的一面和不好的一面。而且这些工程师还还渐渐发现，每当引入一个新的技术来解決一个已有的问题时，这个新的技术就会带来更多的问题，问题就像有一个生命体一样，它们会不断地繁殖和进化。"
- "《架构整洁之道》孙宇聪译，软件架构参考书籍。 第一章 软件架构的终极目标是，用最小的人力成本来满足构建和维护该系统的需求。 软件开发的核心特点:要想跑得快，先要跑得稳。 过度自信只会使得重构设计陷入和原项目一样的困局中。 研发团队最好的选择是清晰地认识并避开工程师们过度自信的特点，开始认真地对待自己的代码架构，对其质量负责。 要想提高自己软件架构的质量，就需要先知道什么是优秀的软件架构。而为了在系统构建过程中采用好的设计和架构以便减少构建成本，提高生产力，又需要先了解系统架构的各种属性与成本和生产力的关系。 第二章 软件系统两个价值维度-----行为价值和架构价值。 软件架构师这一职责本身就应"
- "软件架构师可以根据相关函数被修改的原因、修改的方式及修改的时间来进行分组隔离，并将这些相互隔离的函数分组整理成组件结构，使得高阶组件不会因低阶组件被修改而收到影响"
- "这些工程师们普遍用一句话来欺骗自己：“我们可以未来再重构代码，产品上线最重要！”但是结果大家都知道，产品上线以后重构工作就再没人提起了。市场的压力永远也不会消退，作为首先上市的产品，后面有无数的竞争对手追赶，必须要比他们跑得更快才能保持领先。 所以，重构的时机永远不会再有了。工程师们忙于完成新功能，新功能做不完，哪有时间重构老的代码？循环往复，系统成了一团乱麻，生产效率持续直线下降直至为零。"
- "这就是科学理论和科学定律的特点：它们可以被证伪，但是没有办法被证明。 但是我们仍然每天都在依赖这些定律生活。开车的时候，我们就等于是在用性命担保F=ma是对世界运转方式的一个可靠的描述。每当我们迈出一步的时候，就等于在亲身证明F=Gm1m2/r2是正确的。 科学方法论不需要证明某条结论是正确的，只需要想办法证明它是错误的。如果某个结论经过一定的努力无法证伪，我们则认为它在当下是足够正确的。 当然，不是所有的结论都可以被证明或者证伪的。举一个最简单的不可证明的例子：“这句话是假的”，非真也非伪。 最终，我们可以说数学是要将可证明的结论证明，而与之相反，科学研究则是要将可证明的结论证伪。"
- "根据上述讨论，我们可以得出一个无法逃避的结论：组件结构图是不可能自上而下被设计出来的。它必须随着软件系统的变化而变化和扩张，而不可能在系统构建的最初就被完美设计出来。"
- "首先，软件架构师自身需要是程序员，并且必须一直坚持做一线程序员，绝对不要听从那些说应该让软件架构师从代码中解放出来以专心解决高阶问题的伪建议。不是这样的！软件架构师其实应该是能力最强的一群程序员，他们通常会在自身承接编程任务的同时，逐渐引导整个团队向一个能够最大化生产力的系统设计方向前进。也许软件架构师生产的代码量不是最多的，但是他们必须不停地承接编程任务。如果不亲身承受因系统设计而带来的麻烦，就体会不到设计不佳所带来的痛苦，接着就会逐渐迷失正确的设计方向。"
- "正如我们之前所说，架构师们所追求的目标是最大限度地降低构建和维护一个系统所需的人力资源。那么我们就需要了解一个系统最消耗人力资源的是什么？答案是系统中存在的耦合一一尤其是那些过早做出的、不成熟的决策所导致的耦合。 那么，怎样的决策会被认为是过早且不成熟的呢？答案是那些决策与系统的业务需求（也就是用例）无关。这部分决策包括我们要采用的框架、数据库、Web服务器、工具库、依赖注入等。在一个设计良好的系统架构中，这些细节性的决策都应该是辅助性的，可以被推迟的。一个设计良好的系统架构不应该依赖于这些细节，而应该尽可能地推迟这些细节性的决策，并致力于将这种推迟所产生的影响降到最低。"
目录
用户评论
第一本完整读完的 Uncle Bob 的书，思路很清晰，但通篇读下来似乎最重要的还是对依赖的控制。
一定要有工程经验后再来读软件工程相关的书，不然会觉得都是些很教条枯燥的东西。但是亲身参与过项目开发后再来读，会发现很多都是血泪教训。虽然还未能完全体会精髓，但是已经可以初步体会到一些设计模式的意义了。
Dependency Inversion Principal 划重点
Clean Architecture的图是很简单，但是得到这张图以及应用这张图就很难了。Draw boundary这种事情需要人有足够的经验的才行，否则画不好就悲剧了。Clean Architecture有点像高内聚低耦合，domain为内，infrastructure为外。
电子书；网盘；架构与设计；
系统地学习了 clean architecture很有必要。终于弄清楚了啥是 business logic。
看了一个半月你总算看完了，确实启发很大
高屋建瓴。
1. don't depend on what you don't need
2. depend on abstraction,not concrete implemention
3. low-level details depend on high-level policies
interface yyds
Prentice Hall的其他书籍查看全部
Signal and Power Integrity - Simplified
Core Java, Volume I (10th Edition)
Fundamentals of Applied Electromagnetics
Reseau
Core Python Applications Programming
Financial Accounting Theory
下载
收藏