最近因为领域模型的原因重新来思考这个问题。一起干饭！
本章主要内容
- 如何分层
- 如何定义领域模型
- 一般命名规则
问题：由于是个人开发，在项目开发中，使用EasyCode进行代码生成，所以各层使用的领域模型都是一样的，controller层使用实体类去接受各种参数，正常使用是没有问题，但是在项目运行的过程中，在调用接口的时候会因为多传参数导致意想不到的问题，更重要的是如果有人使用接口进行注入攻击的时候，会更加的痛苦。
1.如何分层
之前的开发过程中，均是使用 controller，service, mapper三层。最近在看了许多blog后，借鉴总结了一下，并会在以后的日常开发中使用：
- Web 层（controller）：主要是对访问控制进行转发，各类基本参数校验，或者不复用的业务简单处理等。
- Service 层：相对具体的业务逻辑服务层。
- Manager 层：通用业务处理层，它有如下特征（可以抽象提取出来的&与外部通信的&解决方案）:
- 对第三方平台封装的层，预处理返回结果及转化异常信息;
- 对Service层通用能力的下沉，如缓存方案、中间件通用处理;
- 与DAO层交互，对多个DAO的组合复用。
- DAO 层：数据访问层，与底层 MySQL、Oracle、Hbase 进行数据交互。
这里要解释一下Manager 层，在我的理解，Manager层即是对service层的扩展与提取，提取在于：不至于让service层过于庞大，让一些特定的操作在特定的包、类中实现，也能体现出整洁性😀。扩展在于：扩展对MVC的扩展😄。
2.如何定义领域模型
因为之前的原因，所以现在项目中，我使用到的领域模型如下：
- DO（ Data Object）：与数据库表结构一一对应，通过DAO层向上传输数据源对象。
- DTO（ Data Transfer Object）：数据传输对象，Service或Manager向外传输的对象。
- VO（ View Object）：显示层对象，通常是Web向模板渲染引擎层传输的对象。
其中，DO即最基本的结构，与数据库表结构对应，取出后，可以根据情况在service中转VO或DTO，之后向外传输，中间的转型只有一次即可。可能在大型的项目会有更细的划分。之后有get到再与大家分享。
3.一般命名规则
分层领域模型规约：
- DO（ Data Object）：与数据库表结构一一对应，通过DAO层向上传输数据源对象。
- DTO（ Data Transfer Object）：数据传输对象，Service或Manager向外传输的对象。
- BO（ Business Object）：业务对象。 由Service层输出的封装业务逻辑的对象。
- AO（ Application Object）：应用对象。 在Web层与Service层之间抽象的复用对象模型，极为贴近展示层，复用度不高。
- VO（ View Object）：显示层对象，通常是Web向模板渲染引擎层传输的对象。
- POJO（ Plain Ordinary Java Object）：在本手册中， POJO专指只有setter/getter/toString的简单类，包括DO/DTO/BO/VO等。
- Query：数据查询对象，各层接收上层的查询请求。 注意超过2个参数的查询封装，禁止使用Map类来传输。
领域模型命名规约：
- 数据对象：xxxDO，xxx即为数据表名。
- 数据传输对象：xxxDTO，xxx为业务领域相关的名称。
- 展示对象：xxxVO，xxx一般为网页名称。
- POJO是DO/DTO/BO/VO的统称，禁止命名成xxxPOJO。
