java开发 结构分层与领域模型的思考

最近因为领域模型的原因重新来思考这个问题。一起干饭！

本章主要内容

• 如何分层
• 如何定义领域模型
• 一般命名规则

问题：由于是个人开发，在项目开发中，使用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。