Java项目设计分享（一）

感觉公司项目的设计还不错，想和大家分享一下，欢迎大家留言指出缺陷和可优化之处。

先来简单介绍下项目的构成情况。

公司使用的是微服务设计，框架采用SSM（Spring+SpringMVC+MyBatis），整个项目拆分成7个微服务项目，项目之间采用dubbo进行接口调用，采用kafka进行非实时通信，采用Redis作为内存锁工具。

每个微项目的构建结构层次大体相同：
不需要页面的项目分为两层：
project-all
|——api
|——core

需要页面的项目分为三个子项目：
project-all
|——api
|——core
|——web

• api项目：对外的接口服务。
• core项目：业务逻辑层，包含：biz层、service层、dao层（注：core层依赖api项目）。
• web项目：页面处理层，包含：controller（注：web层依赖core项目）。

业务层次共分为4层：

• Facade层：负责对接收参数进行合法性校验，以及对请求记录进行内存锁定。
• Biz层：负责主要业务逻辑的整合。
• Service层：负责将请求数据和返回数据进行一些特殊处理。
• Dao层：负责数据的持久化。

请求DTO主要分为2层：
- xxxxReq：api层接收接口传输的最原始dto（注：Req存储在api层）。
- xxxxQuery：用来对xxxxReq进行特殊处理，比如将req接收的时间字段进行格式化等。

响应DTO也分为两层：
- xxxxEntity：数据表直接生成的实体类
- xxxxRes：api层对外接口返回的dto

持久层又分为2层：

• Mapper层：存放mybatis自动生成工具产生的最原始的Model、Mapper和Mapper.xml
• Dao层：存放基于Mapper层扩展的Model、Dao和Dao.xml。Dao继承了Mapper，Dao.xml继承了Mapper.xml

这样的设计很明显的让设计很清晰，尤其是持久层的设计非常便于扩展：Mapper层的文件由于在自动化生成的基础上，完全没有任何的改动，所以当表字段变更的时候，可以直接使用mybatis自动化生成工具覆盖掉之前的Mapper层文件。由于Dao层生成的定制化语句非常少，手动修改的工作量还是很少的。

虽然上面的设计很清晰，但是DTO的设计上存在几个问题：

1.Req和Query存在一个问题：那就是Query和Req的字段是非常近似的，但是Query没有继承Req，这使得在Req增加字段的时候，还得在Query中增加字段，非常麻烦且容易遗漏。

public class BaseQuery implements Serializable{
   

    private static final long serialVersionUID = -435214449318006882L;

    private St