问经验丰富的开发人员和软件架构师是否能够根据设计模式描述整个软件应用程序？

EN

开发人员的一个常见误解是，您可以完全通过组合设计模式来描述应用程序或构建应用程序。编写软件并不是一个选择设计模式，正确安排它们，然后发货的问题。软件开发还没有完全模块化。如果开发人员不能构建完全由设计模式组成的软件，那么软件架构师就不能对完全由设计模式组成的软件进行概念性的讨论。

设计模式是一个特定的问题，加上如何解决这个问题的一般描述。它是一种主要的沟通工具，所以我可以看到有人可能会认为架构师可以在设计模式方面说话。他们确实在设计模式方面发言，但并不存在解决每个问题的设计模式。相反，架构师将从软件设计的更大的图景元素的角度来表达和思考。设计模式当然是架构师词汇的一部分，但它远远超出了这一范围。设计模式、架构模式(洋葱体系结构、清洁体系结构、微服务体系结构)、设计理念(领域驱动设计)和设计技术(关注点分离、接口隔离原则、多态性、封装、数据隐藏等)可以成为主要的通信工具。

所以，没有。架构师不能完全使用设计模式来描述应用程序。他们还需要建筑模式、设计理念和技术。

这在很大程度上取决于应用程序的大小以及架构师正在工作的抽象级别。

如果应用程序是一个琐碎的应用程序(比如学校作业)，用一个众所周知的模式解决一个众所周知的问题，那么它的架构师很可能知道设计模式，并且能够这样描述它。在更大的系统中，这变得困难得多:许多模式重叠，每个解决方案都有一些特定的需求打破某些模式，平台限制迫使偏离，等等。在这种规模下，用设计模式解释整个体系结构变得困难得多，但在某种程度上仍然是可能的。

在拥有数百万行代码(或在某些情况下是数亿行)的大型软件系统中，全新的模式开始出现。理解，甚至仅仅描述在这个范围内发生的事情，仍然可以获得PhD学位。在这种规模下，如果架构师负责某个子系统领导一个团队，他们可以描述自己与设计模式相关的部分，但很可能对整个系统没有或有限的概述。如果架构师正在“系统的顶端”上工作，协调其他架构师、子系统，或者与业务伙伴谈判等等.他们可能会给你一个关于整个系统的描述，但是他们实际上不能给出每个部分是如何工作的详细信息。

请注意，经过一个规模和复杂性，它不再是建筑师的错误，如果他们不能“理解”/“描述”整个系统的细节。规模和复杂性可能超出任何人的能力(或者至少使用我们现有的工具)。

关于大型软件系统的一些个人观察：

• 模块的依赖关系开始形成无标度图：结构分析。
• 雷曼的法律(或者至少是良好的可预见性)开始变得显而易见：质量演变。
• 政治和控制问题可能会开始出现：重构的局限性。
• 等等..。