该同学的代码实现比较到位的实现，约起来活动发布模块的基本数据模型，也能够正常的使用分层的商业代码布局。

其中，对双值枚举的使用以及枚举值的内部方法实现比较到位；对表单接口的较多参数判断也比较严格。

另外，针对活动发布的插入和活动状态流水表的插入使用了事物的注解，不错的想法。

但是依然存在一些问题：

1 对外接口参数做严格校验时没有问题的，但是校验代码量过多，会使后续的代码修改或者维护带来很大的麻烦。

往往翻上一两页，还不知道这个接口的具体业务逻辑是什么？

商业上这个时候会有一个技巧，就是把所有的非法校验，抽离出一个方法，用返回值来标记失败还是成功

2 事务场景的使用是正常的，但是不合理。

在商用环境里面，事物的使用是比较少，因为他必然对性能会产生影响。

但是发布模块的插入和流水的插入，它的权重不一样。就算流水插入失败，也要保证插入的成功，而不会让用户再重新输入一遍。

Java代码 评审视频：
移动端：https://m.naoffer.com/intern/review/487
PC端：https://xiaozhao.vip/intern/review/487