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

清晰架构Clean Architecture，又称干净架构、清晰架构、整洁架构、清洁架构，是著名软件工程大师Robert C Martin提出的一种架构整洁之道。以下是原文大意，原文点击标题进入。

清晰架构无法满足我在许多方面的期望。尽管马丁先生对其表现出了非常的热情，但清晰架构的组织性很差，缺乏实例，并且对现有系统的使用保持沉默。作者错过了一个重要的机会来教我们何时以及如何将这些课程应用到我们自己的系统中。

清晰架构一本组织不良的书

这本书阅读需要很长时间，关于设计范式（结构化，面向对象和函数）的章节似乎特别不合适且不必要。

关于SOLID原则的章节很好。我很高兴看到这些原则被打破并解释得很好。我发现考虑它们对系统架构的适用性很有意思。但鲍勃叔叔提出了像硬规则这样的SOLID原则，这种原则让我会产生误解。事实上，我很确定违反SOLID原则的系统将是一个巨大的混乱系统。

但是，第137页的这一段很重要：

架构的主要目的是支持系统的生命周期。良好的架构使系统易于理解，易于开发，易于维护和易于部署。最终目标是最小化系统的寿命成本并最大化 程序员 的生产力。

这是一个很好的见解，鲍勃叔叔为什么不把它放在第一章？

没有足够的例子

本书几乎没有任何例子。第33章包含一个讨论视频销售电子商务应用程序的示例。我一直在想如何将这些概念应用到我自己的系统中。

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

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

大多数开发人员将大部分时间花在现有系统上。因此，我希望清晰架构这本书能够提供有关改进现有系统的建议。但是这本书在这个问题上显而易见地保持沉默。

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

在本书的前半部分，您将了解到通过遵循SOLID原则创建一个清晰架构，将系统分解为系统边界内的组件。在本书的最后，在第228页：

此示例旨在表明架构边界存在于任何地方。作为架构师，我们必须小心地识别何时需要它们。我们还必须意识到，这些边界在完全实施时是昂贵的。

与此同时，我们必须认识到，当忽略这些边界时，即使在全面的测试套件和重构规则的存在下，它们在以后添加也非常昂贵。

那么我们架构师做些什么？答案是不满意的。一方面，一些非常聪明的人多年来告诉我们，我们不应该提前预测哪些需要抽象。这是YAGNI的理念：“你不需要它。” 这条信息有智慧，因为过度工程往往比工程设计更糟糕。但是，另一方面，当您发现你确实需要一个之前不存在的架构边界时，添加这样的边界的成本和风险可能非常高。

所以你必须看到未来。你必须聪明地猜测。您必须权衡成本并确定架构边界所在的位置，哪些应该完全实现，哪些应该部分实现，哪些应该被忽略。

因此，他说（本书的一半以上），我们应该决定将边界这个概念放在我们的系统中。这种边界可能无处不在。令人困惑，对吧？

（banq注：理解了DDD就知道，这种边界是一种上下文边界，而从哲学上看，这是一种逻辑边界，世界这个词语本身就包含边界，边界是人的主观和客观之间的符号，这是一种三元论世界观，二元论和一元论世界观的人很难理解。）

这本书遗失了什么

因此，如果软件架构的最终目标是最小化系统的生命周期成本，那么架构书是否应该帮助架构师做出这些决策呢？

这本书给我留下了许多未解答的问题。各种选择的经济学讨论在哪里？如何为我的系统找到最佳架构？研究在哪里？

如何确定水平分层或垂直切片或其他什么方法可以最大限度地降低系统的生命周期成本？或者，如果我没有明确定义的架构分层，我如何决定哪种分层策略可以最小化我的生命周期成本？

我还有更多问题。如果你有足够的时间来改进现有系统的架构，你应该把你的努力放在哪里？将数据库与业务逻辑分开是不是总是一个好主意？（banq注：实际系统中大部分是使用数据库实现业务逻辑，因此数据库Oracle等和业务逻辑是混合在一起，而DDD则是让你明白这点，但是做到分离是一种革命性的工作，几代人努力吧。）你应该遵循哪些建议？哪些建议取决于系统？

使Clean Architecture更有价值的细节

在 Code Complete中 ，Steve McConnell讨论了可靠性，可靠性，正确性，可维护性，可读性等不同非功能性需求之间的权衡。他解释了一些需求如何一起变动而与另一些需求发生冲突（banq注：需求概念之间的逻辑矛盾，实现逻辑一致性梳理是必要的，不能等到软件实现以后才发现，这种代价是昂贵的）。对于本书中讨论的架构决策，我本来希望看到类似的内容。

在清晰架构中，项目规模，团队规模，项目失败的后果，预期的代码生存期以及其他重要因素都未被强调为架构的驱动因素。

这本书的真正含义

打个形象的比喻说明这本书含义：

想象一下，您正在为消费市场构建台式计算机（例如办公室计算机）。你可以选择硬件，然后你将为整个事情编写一套系统（包含硬件，操作系统，驱动程序，应用程序，一切）。

你会写一个巨石单体系统吗？你会写一个巨大一整块程序吗？比如使用电子表格编码，它能知道如何为你的计算机选择磁盘类型吗？您能想象任何地方添加“if”语句，以便在您拥有SATA驱动器时执行一项操作吗？如果您有SCSI驱动器则执行另一项操作吗？

那将是一场噩梦，对吧？那么解决方案是什么？架构！您的电子表格代码不应该知道您正在使用哪种磁盘。

那么什么是计算机中的边界？

如果看看你的电脑，那你就会发现：鼠标中有嵌入式软件，可与您的操作系统进行通信。然而，细节隐藏在您的应用程序中。您的电子表格接受标准化输入，而不知道或不关心您使用的是哪种鼠标或磁盘。然后当有人发明像触摸板这样的新输入设备时，它会自动与电子表格配合使用。

这只是您计算机的一个边界。你可能会想出数百个。您可以指派不同的团队来处理系统的不同部分。您可以为不同组件交互的各种方式创建或采用不同的规范。

你可能在这一点上说'呃'。很明显，每次硬件更改时，您都不希望更改和重新编译电子表格。维护将是一场噩梦。

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

很容易看到硬件边界。但是，硬件边界的同样逻辑也适用于软件边界。软件边界很难看到。

因此，您可以从屏幕上显示电子表格的操作开始。可能想将其保存到磁盘，将其保存为PDF，或将其另存为CSV或打印。因此，电子表格程序中的一个边界可能是拥有代表每个电子表格的内部数据结构。然后将该结构传递给不同的代码，以所需的格式显示，保存或打印它。

如果您使数据结构完全解耦它的显示，保存或打印方式，那么您可以在未来的情况下添加“保存到XML”等新功能，这就无需浏览与电子表格数据结构相关的所有代码。如果该电子表格数据结构是数百万行代码，您可以想象添加新功能会有多容易！

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

更好的软件架构书：

在许多方面，Martin Fowler 的企业应用程序架构模式 远远优于 Clean Architecture 。Fowler描述了他在企业应用程序中反复观察到的模式。他给出了一个简单的例子，如果每个模式，描述它是如何工作的，以及在哪里使用它。我发现 企业应用程序架构模式 非常易读并且适用于我的系统。