Facade Design Pattern继承了架构中Facade的概念吗？我的意思是在建筑中，术语Facade通常代表任何建筑物的正面或外部。 Facade Design Pattern在软件架构中是否也有这种用途？如果这是真的，这个概念是否也适用于"Factory Pattern" vs "Factory","Bridge Pattern" vs "Bridge","Proxy Pattern" vs "Proxy"和其他设计模式？“Facade”设计模式与架构的“Facade”
Facade Pattern指过滤信息或墙面大实现/复杂的细节。
它可以像窗帘或墙壁一样放置在一些复杂的方法或体系结构上，以方便访问。这就是Facade Pattern的介绍方式（请参见here的“什么是门面模式”）。您也可以通过Facade隐藏您的课程的一些方法或功能。
最好的例子之一是Repository模式。您可能会隐藏所有数据库逻辑（DTO到Business对象），因为您有一天可能会更改数据库（如SQL到MySql或Oracle，SQL到EntityFramework）。它隐藏了一些东西，比如墙壁，同时展示了一些东西，比如窗户。
对于其他列表，它非常适用。
Factorypattern创建从某个上下文对象不暴露instanciation执行（你的类调用工厂没有建立，工厂一样）Bridgepattern帮助，而不依赖与实现链接抽象（我想要保存到多个数据库，但我希望一个入口点用于所有不同技术的实现）Proxypattern将掩码放在您可能不想创建的对象前面。所以是的，几乎所有的模式在一定程度上都有真实的生活应用。
一般来说，是的。四人帮模式的工作灵感来自于Christopher Alexander。
克里斯托弗亚历山大是第一个研究建筑和社区模式，并开发了一种“模式语言”来产生它们的建筑师。
我发现架构隐喻在很大程度上与软件设计并行。当然，没有比喻是完美的，所以你当然可以找到差异。 GoF指出，
找到好名字是我们的目录开发 最困难的部分之一。
更一般你问的是，“做设计模式名称描述其内部设计的想法，在现实生活中的实体方面？
概念上的答案是肯定的。在你的例子
而且我们也应该注意到它也取决于个人的口味和个人理解。举例解释器模式由GoF引入，其含义是它描绘了一个典型的编程语言解释器（或编译器）。但通常“解释者”一词的意思就像翻译者，所以人们往往会误解这种模式的含义。因为有些人认为它不是那种模式的好名字，有些名字像'表达'会是更好的选择。
因此，我们应该从前面的一点学到的另一件事是，我们不应该直接用我们自己的理解，用什么样的名字暗示，因为它可能与它们的含义有所不同。我们应该先看看他们的真实想法。即他们所建议的编程解决方案是什么。
例如：桥梁模式建议关于桥梁。但在编程方面，它可以达到decoupling the abstraction from ones implementation。