烟囱式开发模式：

上述开发模式有几个弊端：

1. 业务代码重复，业务相似会有大量相似的代码
2. 数据库表结构的变动需要修改设计的dao层，维护成本高
3. 此类相似业务，api层定义各自显示对象，dao层负责获取全量数据（例如，用户查询，就获取整个用户表字段的数据），service层定义业务对象，根据不同api不同业务类型的判断，根据dao查询的数据组转业务对象，以及业务对象向api显示对象的转换。

这样开发模式的优势：

业务代码集中在业务层 service,专注于业务对象 bo 的封装以及业务对象给展示层 vo的转换，封装复用逻辑，可以减少大量重复的代码，后期维护便捷的多。

数据库改动只设计dao层，快速响应各个业务。

业务代码如何拒绝 all in one

以上的controller代码最突出的缺点就是代码完全无法复用，完全没有使用到面向对象封装，集成，多态的特性。业务开发中，一般都是权限校验，参数校验，业务判断，业务对象转换数据库操作。

我的做法是业务抽象，把公共代码进行抽取，通过配置的形式的方式调用，使业务代码可以以可插拔的方式选择指定的权限校验，参数校验。简单来说，就是善用AOP面向切面编程的思想，示例如下：

权限校验：

使用aop对权限校验逻辑进行抽取，能够通过注解的方式指定哪些controller需要进行权限校验。对用户进行数据过滤时，使用controller的拦截器获取该用户拥有的各类权限，并把用户数据保存在上下文threadloal中，并且通过配置对指定url进行拦截。在业务层，从上下文拿到用户权限数据做各类数据业务过滤，通过aop实现各类拦截业务的指定调用。

参数校验：

使用java validtion对通用的字段，例如电话号码，身份证，进行扩展，详细可以参考，如何使用validation校验参数？，在项目中其他类似校验进行复用。

业务判断：使用设计模式对不同类型的业务开发进行封装，集成，多态扩展；这样在后期的扩展中可以基于开发封闭原则，针对新的业务扩展子类即可。

业务对象转换数：

业务开发过程中，依照阿里巴巴研发规范的要求，存在DO(数据库表结构一致的对象)，BO（业务对象）,DTO(数据传输对象)，VO（显示层对象），Query（查询对象）。

使用MapStruct，可以灵活的控制的不同属性值之间的转换规格，比org.springframework.beans.BeanUtils.copyProperties()方法更加灵活。

DB数据库公共字段填充：

例如，公共字段，生成日期，创建人，修改时间，修改人使用插件的形式进行封装，在mybatis-plus中使用MetaObjectHandler，在执行sql之前完成统一字段值的填充。

项目如何做好代码注释？

枚举类的使用：

在业务中特别是状态的值，在对外发布api的vo对象中，加上状态枚举值的注释，并且使用@link 注解，可以直接连接到枚举类，让开发者一目了然。