7层是框架还是架构？
框架：
1、定义：
框架（framework）是整个或部分系统的可重用设计，表现为一组抽象构件及构件实例间交互的方法，另一种定义为，框架是可被应用开发者定制的应用骨架，前者是从应用方面而后者是从墓地的方面给出的定义。
框架是一个可服用的设计构件，通常以构件库的形式出现，但构架库只是框架的一个重要部分，框架的关键在于框架内对象间的的交互模式和控制流模式。
2、框架和构件
框架比构件可定制性强。在某种程序上，将构件和框架看成两个不同但又彼此协作的技术更好。框架为构件提供重用的环境，为构件处理错误，交换数据及激活操作提供了标准的方法。
3、应用框架
应用框架是实现了某应用领域通用完备功能（除去特殊应用的部分）的底层服务。使用这种框架的编程人员可以在一个通用功能已经实现的基础上开始具体的系统开发，框架提供了所有应用期望的默认行为的类集合。具体的应用通过重写子类或组装对象来支持应用专用的行为。
4、框架的特点
① 其实就是某种应用的半成品，就是一组组件，供你选用完成你自己的系统，而且框架一般是成熟的，不断升级的软件。
②框架是一个可复用设计，它是由一组抽象类及其实例间协作关系来表达的。
③一个框架是在一个给定的问题领域内，一个应用程序的一部分设计与实现，也就是说框架是对特定应用领域中的应用系统的部分设计和实现。
5、为什么要用框架
因为软件系统发展到今天已经很复杂了，特别是服务器端软件，涉及到的知识，内容，问题太多。在某些方面使用别人成熟的框架，就相当于让别人帮你完成一些基础工作，你只需要集中精力完成系统的业务逻辑设计。而且框架一般是成熟，稳健的，他可以处理系统很多细节问题，比如，事物处理，安全性，数据流控制等问题。还有框架一般都经过很多人使用，所以结构很好，所以扩展性也很好，而且它是不断升级的，你可以直接享受别人升级代码带来的好处。
架构
1、定义
软件架构（software architecture）是一系列相关的抽象模式，用于指导大型软件系统各个方面的设计，是一个系统的草图，描述的对象是直接构成系统的抽象组件。各个组件之间的连接明确细致的描述组件之间的通讯。
2、如何使用
在实现阶段，这些抽象组件被细化为实际的组件，比如具体某个类或对象，在面向对象领域当中，组件之间的连接通常用接口来实现。软件体系结构是构建计算机软件实践的基础。
3、要素
①它是一个软件系统从整体到部分的最高层次的划分。
一个系统通常是由元件组成的，而这些元件如何形成、相互之间如何发生作用，则是关于这个系统本身结构的重要信息。详细地说，就是要包括架构元件（Architecture Component）、联结器（Connector）、任务流（Task-flow）。所谓架构元素，也就是组成系统的核心"砖瓦"，而联结器则描述这些元件之间通讯的路径、通讯的机制、通讯的预期结果，任务流则描述系统如何使用这些元件和联结器完成某一项需求。
②建造一个系统所作出的最高层次的、以后难以更改的，商业的和技术的决定。
在建造一个系统之前会有很多的重要决定需要事先作出，而一旦系统开始进行详细设计甚至建造，这些决定就很难更改甚至无法更改。显然，这样的决定必定是有关系统设计成败的最重要决定，必须经过非常慎重的研究和考察。
4、设计目标
1.可靠性（Reliable）。软件系统对于用户的商业经营和管理来说极为重要，因此软件系统必须非常可靠。
2.安全性（Secure）。软件系统所承担的交易的商业价值极高，系统的安全性非常重要。
3.可扩展性（Scalable）。软件必须能够在用户的使用率、用户的数目增加很快的情况下，保持合理的性能。只有这样，才能适应用户的市场扩展得可能性。
4.可定制化（Customizable）。同样的一套软件，可以根据客户群的不同和市场需求的变化进行调整。
5.可伸缩 （Extensible）。在新技术出现的时候，一个软件系统应当允许导入新技术，从而对现有系统进行功能和性能的扩展。
6.可维护性（Maintainable）。软件系统的维护包括两方面，一是排除现有的错误，二是将新的软件需求反映到现有系统中去。一个易于维护的系统可以有效地降低技术支持的花费。
7.客户体验（Customer Experience）。软件系统必须易于使用。
8.市场时机（Time to Market）。软件用户要面临同业竞争，软件提供商也要面临同业竞争。以最快的速度争夺市场先机非常重要。
框架与架构区别
1、框架是软件，架构不是软件。
框架是一种特殊的软件，它并不能提供完整无缺的解决方案，而是为你构建解决方案提供良好的基础。框架是半成品。典型地，框架是系统或子系统的半成品；框架中的服务可以被最终应用系统直接调用，而框架中的扩展点是供应用开发人员定制的“可变化点”
软件架构不是软件，而是关于软件如何设计的重要决策。软件架构决策涉及到如何将软件系统分解成不同的部分、各部分之间的静态结构关系和动态交互关系等。经过完整的开发过程之后，这些架构决策将体现在最终开发出的软件系统中；当然，引入软件框架之后，整个开发过程变成了“分两步走”，而架构决策往往会体现在框架之中。
我们不能指着某些代码，说这就是软件架构，因为软件架构是比具体代码高一个抽象层次的概念。架构势必被代码所体现和遵循，但任何一段具体的代码都代表不了架构。
架构、框架、模式
架构、框架、模式是一种从大到小的关系，也是一种组合关系。
架构一般针对议和行业或一类应用，是技术和应用的完美结合。
框架比较小，很多表现为中间件，框架一般是从技术角度解决同类问题，从技术的横切面来解决实际应用问题。
模式就更小了，灵活，可重用的范围更广。
一个框架可能使用了多个设计模式，而一个架构很可能应用了多个框架。
看完了这些概述，你知道7层属于哪个了吗？