我这个模块规划还能再优化一下吗？

Question

先上图，这个是我目前的模块规划
xxx
├── xxx-gateway // 网关模块 依赖xxx-common-core
├── xxx-auth // 认证中心 依赖 xxx-core
├── xxx-api // 接口模块 依赖 xxx-core
├── xxx-common // 通用模块
│ └── xxx-common-core // 核心模块 存放公共依赖
│ └── xxx-common-log // 日志记录,因为本身不做权限调用，依赖 xxx-api
├── xxx-system // 系统模块，主要做rbac权限管理,外带进行日志纪录 依赖 xxx-api
├── xxx-其他业务服务1 //需要日志纪录 依赖 xxx-api
├── xxx-其他业务服务2 依赖 xxx-common-core
├──pom.xml

因为现在想做一个简单的日志纪录，因为考虑到有多个服务可能许需要日志纪录，所以就放到common里了，本来我的common就一层，没有分core、log之类，然后我做的过程我发现因为Log我需要持久化到数据库中，但是common中是不进行数据库操作的，所以我就想到feign远程调用system模块，system模块进行持久化操作。看着可行，但是这样就出现了循环依赖了，因为我api模块会依赖common,然后common中的log又要调用api，这样就出现循环依赖了。

这可不行，我就想着趁现在业务模块还不是很多，赶紧优化一下模块。然后如上图就这样了。我测试了下，目前完全可以跑，但是我总感觉这样不是很好，但又说不上来，有没有更好的模块规划呢？

另外再多提个问题，这个判断有必要吗？我看了一些开源项目，有些有判断，有些没有。

Answer 1

个人感觉：

• 模块问题：log就作为一个模块，要有自己的pom，谁用就引用它，即便是放到common目录中也别和common-core同用一个pom
• 判定问题：新增、删除这两个操作感觉加不加判定大于0都没太影响，因为对于新增，失败直接会抛异常，除非用insert ignore命令可能会返回0，而对于删除，如果不存在会返回0，但是本身我就想删除，没有的话也没必要报错吧；而对于更新的话还是有点影响的，更新不存在时返回0，此时不判定就会有问题，但如果是单条更新，更新前一般都会先查询详情了，那影响也基本没有。虽然这样，但总得来说还是加上判定更好一些。