由于阿里Java开发手册对于工程结构的描述仅限于1、2节简单的概述，不能满足多样的实际需求，本文根据多个项目中工程的实践，分享一种较为合理实用的工程结构。

工程结构的原则

有依据、实用。有依据的含义是指做任何操作都是有理论支持的，而不是完全凭个人喜好，也不是完全效仿大厂行为，因为大厂的业务场景不一定适合自己。比如我们组负责的子系统的特点通常没有复杂的业务逻辑，交互的团队也相对较少。此外，有依据也是说服同事认可该结构的手段之一，毕竟工程结构是大家协作开发的基础。实用的含义是指该结构在真正编程的时候是否方便，比如来来回回copy bean，这就表示需要简化bean的种类了。笔者一直相信好的结构绝不是一蹴而就的，而是有了大的指引方向同时结合自己的项目特点不断地演化而来的。

工程结构的具体内容

2.1 工程结构分层

工程一共分4层，结构图如下

Controller层、Service层、Manager层、Dao层共4层。一个请求从Controller层到Dao层，按照箭头的方向依次向下调用，然后原路返回。

Controller层：控制层。现在很多项目都是前后端分离，前后端使用json数据直接交互，该层承担的功能较少；

Service层：业务逻辑层，每个接口自己的特殊逻辑放在这一层；

Manager层：业务逻辑通用层，每个数据库表可以共用的部分，比如常见的增删改查；

Dao层：数据访问层，根据数据源使用的不同，在具体使用的时调整为具体的方式。

2.2、Bean的种类

根据实际经验建议，设置3种即可。分别是DTO、PO、Param即可。

DTO : 数据传输对象。用在请求即将返回的时候。在Service层使用，在Service层完成PO向DTO的转换。也就是从数据库把数据查询出后，转换为请求需要的数据格式和字段。

PO : 持久化对象。与数据源中存储的表字段一一对应。在Manager层、Dao层使用。根据Param查询出对应的PO对象。

Param : 查询参数对象。一个查询接口对应一个查询对象。在Controller层、Service层、Manager层使用。如果接口的定制性极强，无法复用使用Manager层提供的通用的增、删、改、查方法，Param最终会进入到底层，直接进行在Dao层查询，但是这种情况较少。

2.3 各层的作用及理由

Controller层：

该层应该放哪些内容呢？

1、各类基本参数校验

原因：不放到Service层的原因，可以共用的校验的业务数量很少。以常见的分页和导出为例，这2个功能经常组合出现，可是在处理参数校验的时候可以共用的也并非全部。参数放在此层的另外一个好处是有错误会以最短路径返回。

public class AController {
     
    @GetMapping("/a/list")
    public ResponseBaseDTO<ResponseListDTO> list(@RequestBody RequestDTO requestDTO){
 
        BasicValidator.validateEmpty(requestDTO.getSchoolId(),"schoolId");
        return null;
    }
}

2、组装最终的返回对象

各个接口的返回，比如列表查询、单值查询，需要返回相同格式的数据。处理的位置是在Controller层。在Controller层返回，属于数据渲染处理，比较合适。同时不与Service的业务处理耦合，让其处理看起来比较单一和清爽。

public class AController {
 
    @Autowired
    private AService aService;
 
    @GetMapping("/a/list")
    public ResponseBaseDTO<ResponseListDTO> list(@RequestBody RequestParam requestParam){
 
        BasicValidator.validateEmpty(requestParam.getSchoolId(),"schoolId");
        List items = aService.list(requestParam);
        ResponseBaseDTO<ResponseListDTO<String>> base = new ResponseBaseDTO<>();
        base.setData(new ResponseListDTO<>(items));
        return base;
 
    }
}

对于相同类型的数据返回，统一格式。格式如下。

列表返回

{
    "status": "1",
    "msg": "OK",
    "data": {
        "items": [
            {}
             
        ]
    }
}

Service层：

该层应该放哪些内容呢？

1、定制化接口，定制化逻辑，不考虑复用

不考虑复用指的是不会被2个及2个以上的Controller调用。在一段工程中，总有一个代码块是独一无二的，不与其他人共用，具有自己特殊的逻辑，而这个位置就在Service层。因为共用的代码位置下沉到了Manager层。类之间相互交互是Service直接调用另外一个类的Manager

@Service
public class AServiceImpl implements AService {
    @Resource
    private AManager aManager;
    @Resource
    private BManager bManager;
 
}

2、如果需要控制事务，在此层控制事务

尽可能减少事务嵌套。事务嵌套需要处理事务的传播行为，所以将事务的控制放到不共用的位置，对于事务的处理较为简单，减少出错的可能性。

3、多个查询对象Param满足多样需求

数据对象 PO，对象的字段与数据库表字段一一对应，Param对象可以理解为PO对象的查询封装，从理论上讲Param是PO各个字段的排列组合情况，意思就是对于字符串类型字段，会有等于查询(=)、模糊查询(like)、列表查询(in)等，很多样，实际上真正使用的时候并不会使用到每一种情况，此时一般是需要一个添加一个。举个例子：

代码块

public class PatrolTaskStatusGroupByParam {
 
    private String typeCode;
 
    private Integer schoolId;
 
      
}

public class PatrolTaskStatusRefreshParam extends LoginInfoParam {
 
    private String typeCode;
 
    private Set<String> classCodes;
 
}

这些Param产生的原则是1个接口对应1个Param，至少我们从前端接收参数的时候要1次性接收完毕，拿到Param后在内部涉及多个对象的新增或者修改时，将Param转换为相应的PO,该转化在Service层完成。在Service层调用不同Manager，完成聚合。针对同一个PO对象产生的多个Param对象，每个Param各异，要求返回的对象基本也没有共通性，所以Service层就是定制化模块。

Manager层

该层应该放哪些内容呢？

1、通用功能

典型的增删改查操作；一般借助现有的框架即可，比如mybatis plus

2、该对象复用极高的方法

举例，对于学校对象的查询，当学校ID等于项目中心时，需要返回所有的分校，类似方法复用性极高，需要放入Manager层.

其他对象的Service在调用该对象的方法时，应该调Manager，而不是调Service。因为在Service写的是无法通用的方法，而Manager写的才是通用的方法。

3、调用外围系统方法放在该层

外围系统对于当前系统提供的功能一般不属于定制化功能，而是通用性功能。所以不是放在Service层，而是放在Manager层。另外一个好处是方便进行统一管理。调用外部系统一般http方式较多，放在Manager层，相当于统一入口，不会再分散在程序的各处，在统一设置超时时间、身份信息、请求和返回日志时非常方便管理。

比如我们接收到用户的token，验证用户身份时，需要调用外围系统，并接收外围系统的返回结果以让我们知道当前登录人的信息。该类型方法需要在Manager层暴露接口方法。

4、自己封装的调用中间件的方法

对于中间件的使用，也属于通用性极强的功能。所以不是放在Service层，而是放在Manager层。另外一个好处，和上面的第3条类似，统一入口，方便统一管理。以Redis中常用的get、set为例，对其进行任何操作，都没有必要让上游业务系统感知到。尤其是当出现中间件版本升级等问题时，统一封装，所以代码改动量极小，大大提升工作效率。

Dao层

该层应该放哪些内容呢？

1、数据库操作相关

距离数据源最近，只能处理与数据源相关问题。没有业务逻辑。

当数据源是mysql时，该层一般会借助mybatis框架，编写sql语句，查询表的相关数据，并返回数据供调用方展示；

public interface IUserMapper extends BaseMapper<UserPO> {
}

当数据源是elastic search时，该层借助elastic client 编写dsl语句，查询索引的相关数据，并返回数据供上游方法使用。

@Autowired
    private RestHighLevelClient restHighLevelClient;
 
    public List<Map<String, Object>> searchMap(String index, BoolQueryBuilder bool_query, Integer from, Integer size, String[] includes, String[] excludes, SortBuilder... sort_builders) {
          
        SearchSourceBuilder source_builder = sourceBuilder(from, size, includes, excludes);
        source_builder.query(bool_query);
          
        SearchRequest search_request = new SearchRequest(index);
        search_request.source(source_builder);
        SearchResponse response = restHighLevelClient.search(search_request, RequestOptions.DEFAULT);
          
        List<Map<String, Object>> res = new ArrayList(response.getHits().getHits().length);
        for (SearchHit hit : response.getHits()) {
            Map<String, Object> source_map = hit.getSourceAsMap();
            res.add(source_map);
        }
        return res;
    }

小结

本文核心意图是明确JAVA工程每层所放置的内容。大家在开发的过程中，总是有这样的感觉，放这里合适，放那里也合适的困惑。工程结构属于一种规范，没有最好，只有最合适，希望这篇文章对你在日后的开发过程中有帮助。