◆软件模式为我们提供了一套简洁通用的设计、管理、组织方面的词汇，同时模式也为我们提供了一个描述抽象事物的规范标准，可大大促进软件开发过程中人与人之间的交流，而软件开发中的交流是至关重要的，“软件项目失败的原因最终都可追溯到信息没有及时准确地传递到应该接收它的人”。
架构和模式的关系
因为架构(Architecture)和模式(Pattern)在当前的软件开发中经常地被提及，可是很多人容易混淆这两个术语，而对此，学术界也没有一个非常统一的定义。
架构和模式应该是一个属于相互涵盖的过程，但是总体来说Architecture更加关注的是所谓的High-Level Design,而模式关注的重点在于通过经验提取的“准则或指导方案”在设计中的应用，因此在不同层面考虑问题的时候就形成了不同问题域上的Pattern。模式的目标是，把共通问题中的不变部分和变化部分分离出来。不变的部分，就构成了模式，因此，模式是一个经验提取的“准则”，并且在一次一次的实践中得到验证，在不同的层次有不同的模式，小到语言实现(如Singleton)大到架构。在不同的层面上，模式提供不同层面的指导。根据处理问题的粒度不同，从高到低，模式分为3个层次：架构模式(Architectural Pattern)、设计模式(Design Pattern)、实现模式(Implementation Pattern).架构模式是模式中的最高层次，描述软件系统里的基本的结构组织或纲要，通常提供一组事先定义好的子系统，指定它们的责任，并给出把它们组织在一起的法则和指南。比如，用户和文件系统安全策略模型，N-层结构，组件对象服务等，我们熟知的MVC结构也属于架构模式的层次。一个架构模式常常可以分解成很多个设计模式的联合使用。设计模式是模式中的第二层次，用来处理程序设计中反复出现的问题。例如，[GOF95][2]总结的23个基本设计模式——Factory Pattern, Observer Pattern等等。实现模式是最低也是最具体的层次，处理具体到编程语言的问题。比如，类名，变量名，函数名的命名规则；异常处理的规则等等。
相对于系统分析或者设计模式来说，体系结构从更高的层面去考虑问题，所以关注的问题就体现在“不变”因素上，比如系统部署中，更加关心应用程序的分层分级设计，而在这个基础之上提出的部署方案，才是架构考虑的重点。体系结构关心应用程序模式，更加体现在通过技术去解决这些业务差异带来的影响，关心是否是分布式应用程序，关心系统分层是如何设计，也关心性能和安全，因此在这样的情况之下，会考虑集群，负载平衡，故障迁移等等一系列技术。
希望通过定义的方式来区分架构和模式是不太可能的，因为本来就是交互交叉和提供服务的，它实际上是架构模式，而不是设计模式。在大部份情况下，表现为下面几个设计模式之一：Strategy模式、Mediator模式、Composite模式、Observer模式。对于熟悉架构设计的系统架构师而言，似乎可以用如下来解释架构和模式之间的关系：架构是Hight-Level Design,着眼于不同业务中共性的解决方案，而模式是General Principle(通用原理)。
企业解决方案的构建模式
企业级业务解决方案是公司实现其业务的赌注，它们通常极其复杂，而且性能必须不负众望。它们不仅必须具有高可用性和伸缩性以应对不可预知的使用，而且还必须具有适应性和预见性以适应快速变化的业务要求。最佳解决方案是那些由一组更小的、简单的、能够可靠且有效地解决简单问题的机制组成的解决方案。在构建更大、更复杂的系统过程中，将这些简单的机制组合在一起，从而形成更大的系统。对这些简单机制的认识来之不易。它通常存在于有经验的开发人员和体系结构设计者的头脑中，并且是他们潜意识中自然带到项目中的重要知识。
模式对于开发人员和体系结构设计者非常有用，因为它们：
文章来源于领测软件测试网 https://www.ltesting.net/
