View：视图，为用户提供使用界面，与用户直接进行交互。
Model：模型，承载数据，对用户提交请求进行计算的模块。分为两类，一类称为数据承载Bean，一类称为业务处理Bean。数据承载Bean是指实体类，专门承载业务数据的，如Student、User等。而业务处理Bean则是指Service或Dao对象，专门用于处理用户提交请求的。
Controller：控制器，用于将用户请求转发给相应的Model进行处理，并处理Model的计算结果向用户提供响应。
从图中可以看到，标准的MVC中模型能主动推数据给视图进行更新（观察者设计模式，在模型上注册视图，当模型更新时自动更新视图），但在Web开发中模型是无法主动推给视图（无法主动更新用户界面），因为在Web开发是请求-响应模型。
Web MVC标准架构，如下图所示：
在Web MVC模式下，模型无法主动推数据给视图，如果用户想要视图更新，需要再发送一次请求（即请求-响应模型）。MVC用于将web（UI）层进行职责解耦。
三层架构和MVC的区别与联系MVC严格说是三层架构中的UI层，也就是说，MVC把三层架构中的UI层再度进行了分化，分成了控制器、视图、实体三个部分，控制器完成页面逻辑，通过实体来与界面层完成通话，而C层直接与三层中的BLL进行对话。
三层架构和MVC可以共存。三层架构是基于业务逻辑来分的，而MVC是基于页面来分的。MVC是表现模式（Presentation Pattern），三层架构是典型的架构模式（Architecture Pattern）。
三层架构的分层模式是典型的上下关系，上层依赖于下层。但MVC作为表现模式是不存在上下关系的，而是相互协作关系。即使将MVC当作架构模式，也不是分层模式。MVC和三层架构基本没有可比性，是应用于不同领域的技术。
阿里四层架构三层架构实现比较简单，很多朋友可能觉得项目分层就应该如此，结果就是往往会出现一大堆的业务逻辑都堆砌在Service层中。而在《阿里巴巴 Java 开发手册 》中将原来的三层架构进一步细化，添加了Manager通用业务处理层。
Manager层可以将原Service层的一些通用能力进行下沉，比如与缓存和存储交互策略，中间件的接入；还可以封装对第三方接口的调用，比如调用支付服务，调用审核服务等RPC接口。
通用业务处理层，它有如下特征：
- 对第三方平台封装的层，预处理返回结果及转化异常信息。
- 对Service层通用能力的下沉，如缓存方案、中间件通用处理。
- 与DAO层交互，对多个DAO的组合复用。
其各层的作用如下：
- 终端显示层：各端模板渲染并执行显示的层。当前主要是Velocity渲染，JS渲染， JSP渲染，移动端展示等。
- 开放接口层：将Service层方法封装成开放接口，同时进行网关安全控制和流量控制等。
- Web层：主要是对访问控制进行转发，各类基本参数校验，或者不复用的业务简单处理等。
- Service层：业务逻辑层。
- Manager层：通用业务处理层。
- DAO层：数据访问层，与底层 MySQL、Oracle、HBase 等进行数据交互。
- 外部接口或第三方平台：包括其它部门RPC开放接口，基础平台，其它公司的HTTP接口。
在学习了以上分层架构之后，下面来看一下针对分层在软件系统中的对照关系表：
以上分层定义仅供参考。在上表中还多出了对外接口层和接入层。
对外接口层：所有对外的接口放在这层，不能包含任何业务逻辑，只数据对象的转换和异常的封装。
接入层：所有外部系统的依赖放在这层，好处是一旦外部系统接口修改，只需要在一处修改即可。
DDD分层架构DDD是一种处理高度复杂领域的设计思想，试图分离技术实现的复杂性，同时围绕业务概念构建领域模型，提出的一种软件架构设计的方法论。
DDD分层架构将数据、缓存等都视为基础层， 可以被所有层调用；抽离了领域层，负责核心业务逻辑处理，领域层调用外部依赖全部通过接口，以保证领域层的100%单测覆盖率；应用层聚合多个领域层的能力，只做功能的组合、转发，不负责具体业务逻辑。
我们这里只做DDD分层架构的简单介绍，关于DDD概念不做过多拓展，相关架构模式可专门进行学习一下。看一下DDD分层的架构图：
