1.架构,首先是一个骨架的概念,所以它包含的东西应该是泛而概括的东西,它应该是一个对实现的总体勾勒描述,不应该是一个具体的实现.架构应该为后续的实现提供思想指导。
其次这个骨架应该描述各个部分(子系统/异构系统/构件)之间的接口定义,这些定义提供实现时的总体规范及系统布署时的描述规范.
最后这个骨架应该是搭建起来的技术上验证通过的：稳定的、容变的、可执行的系统。一般地一个架架构是为一个具体的系统设计的。
2.框架 首先也是一个骨架的概念,但它是面向某一技术领域(侧重点)或业务领域--更多是技术领域提供的一个具体实现,这个具体不是象项目开发那样对业务需求的具体化实现，它是对一种技术领域或业务领域的具体化实现。在应用某一框架做一个具体的实现时（比果开发一个具体的业务系统），我们需要参照框架的具体实现规范,这个实现规范为应该做到了最大化的重用性与解决某一技术问题的特殊性。 网上搜一下，现在开源框架多了，大多是解决某一技术领域而提出的。但解决业务领域问题的框架由于商业原因大多不开源的（看来开源在不涉及利益时是可以，反之而不行，再看看MS在做开源上有多难，又开源了些什么东西你就明白了）
3.模式 为解决某相似性问题而提供的通用解决方案(一类大致相同的问题),这些问题具有相似性，并且解决方法也具有想似性，自从模式被“建筑学界”使用之后，这种解决相似性问题的通用解决方法被归类、记录,随后它们被称作为模式被应用。
我想说的是，即然架构是为一个系统设计，那么为设计相类的系统(相似的系统是需要解决的问题，那么通用的架构是解决方案)应该可以参照某一种模式；即然框架是为解决某一技术或领域问题而生，那么一类相似的技术问题也应解决它们的方案--模式。所以模式描述与解决问题的更高级抽象，架构设计与框架设计时离不开模式(尽管你没有明确的写出你应用了哪个模式，或许它早已默化在你的脑海里了）
