Bob Martin的“ Clean Architecture”是所有架构的经验法则还是只是其中之一？

我非常喜欢Bob Martin叔叔的视频“清洁建筑的原理”中的概念。但是我觉得这种模式就像是抽象工厂和生成器模式的组合核心。

这是编写好的程序的一种方法，但不是唯一的方法。

Rails和reactjs是想到的两个框架，它们不会促进这种干净的体系结构。Rails希望您的业务逻辑出现在模型中（FatModels和SkinnyControllers），并在组件内部做出反应。两种方法都将业务逻辑和框架代码紧密结合在一起。

我没有发现这3种方式中的任何错误。这是一个选择任何人的判断电话。

但是在视频中，我觉得他建议干净的架构应该在业务逻辑和框架之间有明确的界限。框架（网页，Android等）应该是插件，插件中的业务逻辑。他甚至在视频中巧妙地嘲弄了轨道。

那么，鲍勃·马丁（Bob Martin）的“清洁架构”是否是所有架构的经验法则，还是只是其中一种选择？

尽管“干净的体系结构”很好并且具有许多优点，但请记住以下几点很重要：

• 清洁架构很大程度上是罗伯特·C·马丁（Robert C. Martin）的品牌重塑和发展，例如杰弗里·帕勒莫（Jeffrey Palermo）的洋葱架构（Onion Architecture）和阿利斯泰尔·考克本（Alistair Cockburn）等人的六角结构（“端口和适配器”）（<2008）。

• 不同的问题有不同的要求。干净的体系结构和相关方法将去耦，灵活性和依赖项转换最多提高了11种，但是却牺牲了简单性。这并不总是一件好事。

这些架构的先驱是Smalltalk的经典MVC模式。这使模型与用户界面（控制器和视图）分离，因此模型不依赖于UI。MVC有很多变体，例如MVP，MVVM等。

更复杂的系统不仅只有一个用户界面，而且可能有多个用户界面。许多应用选择提供一种可由任何UI使用的REST API，例如Web应用或移动应用。这样可以将服务器上的业务逻辑与这些UI隔离开，因此服务器无需理会哪种类型的应用程序对其进行访问。

通常，服务器仍依赖于后端服务，例如数据库或第三方提供程序。这非常好，并导致了简单的分层体系结构。

六角架构走得更远，不再在前端和后端之间做出区分。任何外部系统都可以是输入（数据源）或输出。我们的核心系统定义了必要的接口（端口），并为任何外部系统创建了适配器。

进行强去耦的一种经典方法是面向服务的体系结构（SOA），其中所有服务将事件发布到共享消息总线并从共享消息总线使用事件。微服务后来也推广了类似的方法。

所有这些方法都具有优势，例如，可以更轻松地单独测试系统（通过用模拟实现替换它所连接的所有外部系统）。它们使为一种服务提供多种实现（例如添加第二个支付处理器）或交换服务的实现（例如从Oracle数据库迁移到PostgreSQL或通过在Go中重写Python服务）变得更加容易。。

但是这些架构是法拉利的架构：价格昂贵，而且大多数人不需要它们。清洁架构等的增加的灵活性是以更复杂的代价为代价的。许多应用程序（尤其是CRUD Web应用程序）无法从中受益。隔离可能发生变化的事物是有意义的，例如通过使用模板来生成HTML。隔离不太可能更改的事物（例如，支持数据库）没有意义。可能更改的内容取决于上下文和业务需求。

框架对即将发生的变化做出假设。例如，React倾向于假设组件的设计和行为会一起改变，因此将它们分开是没有意义的。很少有框架假定您可能要更改框架。因此，框架确实存在一定数量的锁定。例如，Rail依赖于（非常自以为是！）Active Record模式，因此很难将数据访问策略更改为（通常是高级）存储库模式。如果您对变更的期望与框架不匹配，则使用其他框架可能会更好。许多其他Web框架不对数据访问做任何假设。

我真的很喜欢Bob Martin叔叔的视频“清洁建筑的原理”中的概念。但是我觉得这种模式就像是抽象工厂和生成器模式的组合核心。

差远了。

当您查看此内容时：

您正在查看对象图的设计。这决定了对什么的了解。这个故事缺少的是如何建立对象图。抱歉，在这里找不到。没有提及构造。

您可以在没有抽象工厂和建造者的情况下构造所有这些东西。我知道，因为我已经做到了。我什至没有着手避免它们。我爱他们。我只是没有碰巧需要它们。我只是使用了引用传递。依赖注入是它的幻想。

实际上，我可以构建您在主视图中看到的所有内容。然后，只需对一个对象调用一个方法即可开始整个过程​​。

现在，必须先存在事物，然后才能将它们推入其他事物。我在这里进行了探索，并给出了这个可爱的小图：

您甚至都可以离开而构建所有这些main()。

当您要将一堆程序构造代码分解成一口大小的概念性块时，我建议使用构建器和工厂。但是，在干净的体系结构或任何其他流行术语体系结构中，没有什么要求您这样做。因此，如果您想坚持main()，那就好。请求饶。

Bob Martin的“ Clean Architecture”是所有架构的经验法则还是只是其中之一？

我认为“清洁建筑”是一个流行语，用于将人们吸引到博客和书中。该博客和书籍对非常相似的较旧体系结构做了很好的解释，这些较旧的体系结构使用较旧的名称来将人们吸引到较旧的博客和较旧的书籍。特别是洋葱以及端口和适配器。这些都不是您唯一的体系结构选择。

我喜欢Bob叔叔，因为他是一位很棒的公开演讲者和作家。他让我想起了我本来没有的事情。但是，如果您让自己变成一个虔诚的狂热者，坚持必须按照自己的方式做所有事情，那么您会很快发现更新文档是最接近我的代码的地方。

当您的代码寿命长，并且环境不断变化时，这些术语必须保持不变，因此流行语体系结构非常有用。那是它的光芒。如果与代码相比世界是稳定的，那么您就没有充分理由使事情变得幻想起来。

不管事物看起来有多棒，您都可以在其中添加上下文以使其变得荒谬。抱歉，这也不是灵丹妙药。

但是在视频中，我觉得他建议干净的体系结构应该在业务逻辑和框架之间有明确的界限。框架（Web，Android等）应该是插入业务逻辑的插件。他甚至在视频中巧妙地嘲弄了轨道。

你是对的。他是这样的。鲍勃叔叔认为框架可以像库一样对待。他们可以。但是即使是这样的决定也会花费您一些钱。

马丁先生想要保留的空间是您的通用语言仍然通用的空间。当您将框架分布到各处时，您就放弃了。当您这样做时，您正朝着将语言转变为称为领域特定语言的道路前进。HTML是领域特定的语言。它的工作做得很好，但是还有其他工作根本做不到。

只要框架能够满足您的需求，一切都会非常顺利。期望您的需求很好。它使您处于使事情简单的盒子中。只需了解您为获得此目标而付出的一切即可。如果您将Spring传播到任何地方，您将无法再将其作为Java工作来宣传。这是Java / Spring工作。我可以对Ruby和Rails说同样的话，但是Rails很久以前就吃过Ruby的午餐。

引用视频：

“您不想在SQL中进行邮件合并。”

其次是：

“我实际上看到了一个SQL存储过程，它是整个邮件合并”

与邮件合并一样，该体系结构只是众多体系中的一种。

架构试图解决的问题不是可选的。

如果您了解SQL邮件合并与其他解决方案相比会引起什么问题，那么您的体系结构选择将得到通知，即使您被迫选择“不良”解决方案，您也将意识到并缓解其不足。

如果您只是因为考虑周全而遵循建筑风格，那么您很可能会犯错误并遇到相同的问题。

“清洁架构”绝对是“唯一”的选择之一。我认为对于大多数项目，尤其是面向对象的项目，这是不好的选择之一。

以下是鲍勃叔叔有关清洁建筑的文章的逐句分析，并指出了上述原因：

从面向对象的角度看清洁架构

清洁体系结构是一组原则和模式，用于解决软件开发组织在构建复杂应用程序的整个生命周期中经常面临的许多常见症状。马丁先生在书中竭尽全力，根据其在该领域的丰富经验来确定症状和根本原因，并阐明体系结构在减轻这些担忧中的作用。

但是，这不是一个经验法则，也不是万灵药。如果您阅读这本书，您将更好地了解是否/何时/如何应用他所倡导的原则和模式（以及所涉及的取舍）。如果您还没有读过这本书，您可能会基于不完整的信息做出错误的假设，应用，判断和陈述。