学习大纲
1、 三层职责
2.、引入领域驱动设计
3、何为限界上下文
4、何为领域
5、领域分层
6、实体和值对象
7、Service
8、生命周期之聚合
9、生命周期之Factory
10、生命周期之Repository
11、命名规范设计
12、贫血模型
13、领域服务
一、MVC模式
用一种业务逻辑、数据、界面显示分离的方式
View。
负责与页面的交互，现实数据的输入和输出
Model。
主要负责处理业务逻辑以及数据库的交互。
Controller负责调度View层和Model层，主要接收请求，然后转发到Model处理，处
理后返回视图。
MVC的目的是将M和V的实现分离，实现Web系统的职能分工。
二、三层架构
1 、Dao层主要是对数据的基本操作，包含构造SQL、参数等。
2 、Service层负责领域业务的处理，负责逻辑处理及转换。对流入的逻辑性数据的
正确性及有效性负责，对流出的逻辑性数据及用户性数据不负责。
3 、Web层不承担任何业务逻辑，主要做于业务无关的操作和逻辑的编排优点。
优点
1 、降低层与层之间的依赖。
2 、达到各层复用的目的。
缺点
1 、拉长了行为的链路，降低了性能。
2 、新增功能时需要在每层变动，增加了开发成本。
三、两者的区别
MVC模式的目的是实现Web系统的职能分工，即职责划分
三层架构的目的着重点是“高内聚，低耦合”
先有架构设计，再使用设计模式
四、阿里规约
开放接口层：可直接封装 Service 方法暴露成 RPC 接口;通过 Web 封
装成 http 接口;进行 网关安全控制、流量控制等。
Web 层：主要是对访问控制进行转发，各类基本参数校验、异常处理
等。
Service 层：相对具体的业务逻辑服务层。
Manager 层：通用业务处理层，它有如下特征:
1 、对第三方平台封装的层，预处理返回结果及转化异常信息。
2 、对Service层通用能力的下沉。
3 、与DAO层交互，对多个DAO的组合复用。
DAO 层：数据访问层，与底层 MySQL、Oracle、Hbase 进行数据交互。
五、出现的问题
Web层的逻辑比Service层还多，各层职责越界了。
Entity/Map/JSON对象透传所有层。
六、明确规范
用户界面层
用户界面层负责向用户显示信息和解释用户指令。这里指的用户可以是另一个计算机系统，不一定是使用用户界面的人。
该层包含与其他应用系统（如web服务、RMI接口或web应用程序以及批处理前端）交互的接口与通信设施。
它负责输入参数的解释、验证以及转换。另外，它也负责输出参数的序列化，如通过HTTP协议向web浏览器或web服务客户端传输HTML或XML，或远程Java客户端的DTO类和远程外观接口的序列化。
可以看出，该层的主要职责是与外部用户（包括web服务、其他系统）交互，如接受用户的反馈，展示必要的数据信息。主要包含web部分和远程服务部分等。
web部分一般包含常见的Servlet，Controller等组件。
应用层
用于接收外部的请求，是整个系统所提供能力的入口。专用于处理与业务无
关的操作，包含验签、参数校验、拦截等处理，通过编排业务领域和外部请
求，对外提供细粒度的能力。
业务领域层
业务领域层主要用于实现业务逻辑，包含业务规则、策略和流程。
基础设施层
基础设施层为以上各层提供技术支持，例如持久化操作、公用的操作等六、分层模型转换。
分层的目的是为了明确职责，每层就会有各自的数据模型。
1 、Request、Response对象只能出现在应用层。
2 、Request‐‐>Model、Model‐‐>Response都在应用层处理。
3 、Model‐‐>Entity、Entity‐‐>Model都在业务层中的仓储层。
七、分层模型转换
分层的目的是为了明确职责，每层就会有各自的数据模型。
1、Request、Response对象只能出现在应用层。
2、Request‐‐>Model、Model‐‐>Response都在应用层处理。
3、Model‐‐>Entity、Entity‐‐>Model都在业务层中的仓储层。
