软件架构之美，之重要，致使多少人迷失其中。许多盲目追求者，甚至连架构、框架、模式三者之间的关系与区别都分不清，将架构与框架等同的误解现象普遍存在。本人并非功力深厚的大师，却也多多少少在此领域有了自己的体会与感悟，也曾如同大多数人在设计面前迷失，沉沦。只有坚持这个设计，懂得适当放弃过度设计的思想，方能跳出地狱，体会天堂的快乐。本文旨在简要的帮助大家区分架构、框架、模式，与大家共同步入设计的天堂，一起感受设计之美，设计之优雅。
首先声明，本文中的架构，指的是软件架构
一、框架（Framework）
许多程序员从入门到熟悉到，会开始对众多高手口中的架构、框架等等叫法产生浓厚的兴趣，并且常常因为使用高手们通过沉淀积累而得到的框架进行开发时感到格外轻松而兴奋不已，因为这些框架通常解决了常常碰到的基础业务问题、开发维护问题。然后，这套被用来做开发的半成品，并不是架构(Architecture)，而是框架(Framework)。更为简单明了的说法，框架是一套半成品软件系统，是一套代码（有时可能也包括一些通用基础业务的数库表或者其它成形的设计）。而架构并不是代码，是一种解决方案，是解决问题的综合体，这在后面会说到。
我们说回框架，像struts、spring、hibernate这些非常著名的开源框架，它们都是针对某一方面的应用而提出解决问题的半成品软件。比如说struts专门用于解决前端开发，是MVC实现的一种很好的解决方式。spring解决的范围就广了，它的web组件同样用于解决前端开发，而ioc容器则用于解决对象之间的解耦与分离，AOP则更是将对象方法之间的协作问题提升到神不知鬼不觉的情况下解决掉（牛啊），当然，spring还有持久化，缓存，事务等方面的专门解决组件，是通过对其它著名框架的集成而得到的。这样我们会发现，当我们想解决某一类问题时，我们不用从零开始编写代码，框架已经为我们封装好了一套解决方法，提供了API给我们使用。总之，框架并不是现成可用的应用系统。它只是一个半成品，需要后来的开发人员进行二次开发，实现具体功能的应用系统。
那么，这些框架为何如此优秀，是如何被设计出来呢？它们的优秀，在于一方面很好地解决了某一领域的问题（或多个领域），让我们不再从零开始造轮子；另一方面也在于它们相对于其它同样解决此问题的方法中，具有较好的性能。我想一个封装得再好的框架，如果性能低劣差劲，是不会被人追棒的。真正封装得好的框架，让我们不必去关心这个框架究竟是怎么产生的，只需调用api就能完成我们的开发，这才是方便的框架。要设计出这样的框架，我们就要有想法，有思路，有设计。而我们通过某种方法或某种思想来解决某种问题，这便是设计模式了。请看下面。
2、设计模式（Design Pattern）
通过上面那段话的介绍，我们就可以这样理解，设计模式并不是什么代码，它，只是一种思想，一种解决问题的方法。大多数人以为设计模式就是代码，其实设计模式是一种思想，而代码，仅仅是用来表达你的思想，将很抽象的思想上的东西用代码活生生的形象的表达出来而已。而模式与框架，它们是软件设计上的两个不同的研究领域。但是，为了得到一个优秀的框架，我们总要想方设法去进行抽象进行设计，以期达到可复用、易维护、低耦合等目标，因此我们需要利用适当的模式来进行设计，再用代码给予实现。
当然，设计模式的作用并不是仅仅用来设计框架，那样理解就过于片面。设计模式是给出了某一个单一设计问题的解决方案，并且这个方案可在不同的应用程序或者框架中进行应用。设计模式仅仅是一个单纯的设计，这个设计可被不同语言以不用方式来实现，可以在不同应用中复用；而框架则是模式和代码的一个混合体，编程者可以用各种方式对框架进行扩展，进而形成完整的不同的应用。
可是我们的开发并非是以模式和框架为指导的，我们在不同的应用开发中，需要遵循不同的规约，这些规约包括了整体结构、层次划分、不同部分之间的协作、功能边界、系统性能处理、适当的技术选型、框架使用、模式应用、是否分布式、代码规范等等因素。而这些因素中的任何一个，都是非常重要的，这些因素综合起来构成了我们的开发规约。而针对这些因素的综合考虑，提出解决开发应用中问题的方案，便是架构。
3、架构(Architecture)
这可能说得不够清晰，学术性点的表达就是，架构包括了一系列的部件、部件之间的关系、部件接口，它体现了对基础原理的决策。架构是对软件系统的系统组织，是对构成系统的构件的接口，行为模式，协作关系等体系问题的决策总和。它不仅涉及到结构与行为，而且还涉及到系统的使用、功能、性能、适应性、重用性、可理解性、经济性和技术约束的权衡和美学考虑。一般而言，软件系统的架构有两个要素：
·它是一个软件系统从整体到部分的最高层次的划分。
一个系统通常是由元件组成的，而这些元件如何形成、相互之间如何发生作用，则是关于这个系统本身结构的重要信息。详细地说，就是要包括架构元件（Architecture Component）、联结器（Connector）、任务流（Task-Flow）。所谓架构元素，也就是组成系统的核心"砖瓦"，而联结器则描述这些元件之间通讯的路径、通讯的机制、通讯的预期结果，任务流则描述系统如何使用这些元件和联结器完成某一项需求。
·建造一个系统所作出的最高层次的、以后难以更改的，商业的和技术的决定。
在建造一个系统之前会有很多的重要决定需要事先作出，而一旦系统开始进行详细设计甚至建造，这些决定就很难更改甚至无法更改。显然，这样的决定必定是有关系统设计成败的最重要决定，必须经过非常慎重的研究和考察。