清洁架构为什么我不推荐 Robert C Martin 的清洁架构

《清洁架构》在很多方面都未能达到我的预期。尽管 Martin 先生对这个主题充满热情，但其内容组织混乱，缺乏示例，并且没有提到如何将其应用于现有系统。作者错失了一个重要的机会，没有教我们何时以及如何将这些经验教训应用到我们自己的系统中。让我来解释一下。

《清洁架构》是一本组织混乱的书

这本书读起来费了好长时间。关于设计范式（结构化、面向对象和函数式）的章节显得格格不入，毫无必要。

关于 SOLID 原则的章节写得很好。我很高兴看到这些原则被分解并清晰地解释。而且我发现思考它们在系统架构中的应用也很有趣。但是 Bob 大叔把 SOLID 原则描述得像硬性规定一样，这让我很不舒服。事实上，我相当肯定，一个从未违反 SOLID 原则的系统将会是一团糟。

然而，第 137 页的这一段很重要：

架构的主要目的是支持系统的生命周期。良好的架构使系统易于理解、易于开发、易于维护和易于部署。最终目标是最大限度地降低系统的生命周期成本，并最大限度地提高程序员的生产力。

这观察太棒了。为什么鲍勃叔叔不把它写在第一章呢？

例子不够

这本书几乎没有例子。第33章包含一个讨论视频销售电商应用的例子。还行。但我读完之后并没有对如何将这些概念应用到我自己的系统中有一个清晰的思路。

附录讲述了鲍勃叔叔是如何提出 SOLID 原则和清晰架构规则的故事。附录里充满了过去项目的例子。我认为这是本书最有趣的部分。

本书没有提及改进现有系统的架构

大多数开发人员大部分时间都在现有系统上工作。因此，我原本以为《清晰架构》会充满改进现有系统的建议。但这本书却明显地对此保持沉默。

如何创建一个干净的架构？

在本书的前半部分，你将学习如何创建清晰的架构，即遵循 SOLID 原则，将系统沿着系统边界（我在此解释）拆分成组件。如果你读到这里就停下来，你可能会觉得 Bob 大叔不会赞同你为架构所做的一切，这完全可以理解。你也可能认为他提出的几个选项就是“正确”的做法。然而，在本书的结尾，你会在第 228 页看到这样的话：

这个例子旨在表明，架构边界无处不在。作为建筑师，我们必须谨慎地识别何时需要它们。我们还必须意识到，全面实施这些边界的成本是昂贵的。

同时，我们必须认识到，当忽略这些边界时，即使有全面的测试套件和重构规则，以后添加它们的成本也会非常高。

那么，作为架构师，我们该怎么办呢？答案令人失望。一方面，多年来，一些非常聪明的人告诉我们，我们不应该预测抽象的需求。这就是YAGNI的哲学：“你不会需要它。”这句话很有道理，因为过度设计通常比设计不足更糟糕。另一方面，当你发现你确实需要一个架构边界，而实际上并不存在时，添加这样的边界的成本和风险可能会非常高昂。

所以，就是这样。软件架构师啊，你必须看清未来。你必须明智地猜测。你必须权衡成本，确定架构的边界在哪里，哪些应该完全实现，哪些应该部分实现，哪些应该忽略。

所以，他在书中超过一半的内容中提到，我们应该决定在系统中设置哪些边界。而且边界可能无处不在。这很令人困惑，对吧？

这本书缺少什么

因此，如果软件架构的最终目标是尽量减少系统的终生成本，那么一本关于架构的书籍难道不应该帮助架构师做出这些决策吗？

未解答的问题

这本书给我留下了很多未解的问题。关于各种方案的经济性讨论在哪里？如何找到适合我的系统的最佳架构？相关研究在哪里？

我该如何判断水平分层、垂直切片或其他方法是否能够最大限度地降低系统的生命周期成本？或者，如果我没有明确定义分层，我该如何决定哪种分层策略（如果有的话）能够最大限度地降低我的生命周期成本？

我还有更多问题。如果你只有有限的时间来改进现有系统的架构，那么应该把精力放在哪里？将数据库与业务逻辑分离总是一个好主意吗？你应该始终遵循哪些建议？哪些建议取决于具体的系统？

使清洁架构更有价值的细节

在《代码大全》中，Steve McConnell 探讨了各种非功能性需求之间的权衡，例如可靠性、可依赖性、正确性、可维护性、可读性等等。他解释了一些需求如何协调一致，而另一些需求又如何相互冲突。我真希望本书中讨论的架构决策也能有类似的内容。

在《清晰架构》中，项目规模、团队规模、项目失败的后果、预期代码生命周期以及其他重要因素作为架构的驱动因素被低估了。例如，Healthcare.gov 比你正在开发的个人待办事项列表需要更多的架构，即使它们都是基于数据库的 Web 应用。

这本书的真正内容

我读这本书的大部分时间都有点困惑。我大概明白鲍勃叔叔想说什么。但直到读了附录才完全明白。所以，让我帮你节省点时间吧。

一个例子

想象一下，你正在为消费市场（例如办公电脑）打造一台台式电脑。你需要选择硬件，并负责编写整套软件（固件、操作系统、驱动程序、应用程序等等）。

你会写一个整体吗？

你会怎么做？你会写一个巨型程序（一个整体），让电子表格的代码知道你为电脑选择的磁盘类型吗？你能想象更新电子表格代码，在各个地方添加“if”语句，这样当你有 SATA 驱动器时，它会执行一种操作，而当你有 SCSI 驱动器时，它会执行另一种操作吗？然后对 VGA、DVI 和 HDMI 视频也做同样的操作吗？PS/2 和 USB 鼠标输入采用不同的路径怎么办？然后对文字处理器以及你打算捆绑到电脑的所有其他应用程序重复这个过程吗？

维护起来会是一场噩梦，对吧？那么解决方案是什么？架构！你的电子表格不应该知道你用的是什么鼠标，也不应该知道你用的是什么显示器。它应该完全忽略这些细节。

计算机中的边界

如果你观察一下你的电脑，就会发现这一点。你的鼠标里嵌入了与操作系统通信的软件。然而，这些细节对你的应用程序来说是隐藏的。你的电子表格可以接受标准化的输入，而不需要知道或关心你使用的是什么类型的鼠标。然后，当有人发明了一种新的输入设备，比如触摸板，它就会自动与你的电子表格兼容。

这只是你计算机中的诸多边界之一。你可能会想出数百个这样的边界。你可能会指派不同的团队负责系统的不同部分。你可能会针对不同组件交互的不同方式创建或采用不同的规范。

看到这里，你大概会觉得“这又怎么样？”。显然，你肯定不想每次硬件更新后都要修改并重新编译电子表格。那样维护起来简直是一场噩梦。我同意你的看法。

界限是你的朋友（如果你正确使用它们）

硬件边界很容易识别。但硬件边界值得遵循的逻辑也适用于软件边界。只是软件边界更难识别。

因此，您可能首先希望能够在屏幕上显示电子表格。但您可能还希望将其保存到磁盘、保存为 PDF、保存为 CSV 或打印。因此，您的电子表格程序的其中一个功能是拥有一个代表每个电子表格的内部数据结构。然后，您可以将该结构传递给不同的代码，以便以所需的格式显示、保存或打印它。

如果您完全不了解数据结构的显示、保存或打印方式，那么以后就可以添加“保存到 XML”功能，而无需深入研究与电子表格数据结构相关的所有代码。如果电子表格数据结构有数百万行代码，您可以想象这会多么容易。

这就是鲍勃大叔在这本书里试图告诉我们的全部内容。你可以使用 SOLID 原则在你的系统中创建边界，隐藏你的实现细节，降低复杂性，并帮助你降低系统的总生命周期成本。

一本更好的软件架构书

Martin Fowler 的《企业应用架构模式》在很多方面都远胜于《清晰架构》。Fowler 描述了他在企业应用中反复观察到的模式。他为每个模式都提供了一个简单的示例，描述了它的工作原理以及适用场景。我发现《企业应用架构模式》非常易读，并且非常适合我的系统。

总结

清洁架构中有一些有价值的信息，但你必须努力才能找到它。

我发现关于嵌入式软件的章节是最容易理解的章节之一。直观地讲，避免在代码库中散布低级调用是合理的。而且，确保你的逻辑在没有硬件的情况下可测试也是合理的（尤其是因为嵌入式软件通常是在硬件可用之前开发的）。如果你只能读这本书的两章，我建议你选择这一章和附录，无论你以编写哪种软件为生。

总的来说，《清晰架构》（Clean Architecture）读起来很难，Bob叔叔给我留下的问题比答案还多。我绝对不推荐你把它作为软件架构的第一本书（建议你去看看Martin Fowler的《企业应用架构模式》）。

同意或不同意，我很想听听你的想法。

喜欢这篇文章吗？请在下方点赞。