按业务拆分模块的疑惑

题主你好
首先说哈，我这边确实看不到图哈，没骗你，可能你的图是其他网站的链接，我这边没有权限

F12看了哈，403的报错，貌似是这个网站的 https://img.hacpai.com ，这是一个三级域名，二级应该是 hacpai.com ，没见过这个域名，搜了哈，是叫 黑客派 这个网站，也是一个程序员网站

好吧，按照题主的问题名称搜索了哈，终于找到对应的 提问 ，也终于可以看到题主的贴图。。。

言归正传，针对你的问题，由于是设计类问题，其实是没有绝对答案的，所以我根据自己的经验做一些回答，仅供参考，但是回答之前要说一个我自己理解的设计理念

最好的设计 = 符合需求 + 截至时间 + 最低物理资源成本 + 最低人力成本

换句话说就是：在有限资源和有限人力的情况下，截至日期内做出符合需求的产品，则此产品的设计就是最好的设计

所以设计的好坏，其实没有绝对的标准，在满足上诉4个条件下的设计，那就是最好的设计

由于题主是自己写的，看起来也不是商用版，现在也不会部署，所以没有截至时间，也谈不上物理资源，自己一个人写，也没有人力成本，最后对于题主来说，只有 符合需求 了，符合需求的设计那就是好设计了

而从下面这句话可以看到，以后不同的 web 项目，但是是基于相同的业务，也就是相同的 business

如果题主的需求如此，那我可以说题主现在设计很合理了啊

那简单画图就是这样

因此把 controller 单独放到一个 web 工程里就没毛病啊

但是题主提到，别人是按业务模块划分，模块内 entity 、 repository 、 service 、 controller 分层，那题主你确定别人这样做，是符合你的需求么？因为别人这么做，也许有别人自己的需求支撑啊...

先不说题主提到的若是这么做会有以下怪怪的问题

光是这么做之后，有个严重问题就是，我之前画的图，可能变成这个样子了

从题主你的 web 项目划分来看，你一个 User 模块，或者 Order 模块里的 controller 已经耦合了其他项目的 controller 了，尤其是对于前端更不友好，假设业务模块更多，他们要到处去找自己要的接口，毕竟每一个模块的接口地址开头都不一样，更不说类似功能但是是不同 web 项目使用的情况下可能造成接口调用错误

当然题主说的依赖起来会有点怪怪的感觉，其实就是 controller 这层， controller 对下连接了业务，对上也连接了不同的项目，一个业务是可以在不同项目中使用的，但是完全不相关的项目是不可以在其他项目中使用的，这就是怪怪的感觉，去掉 controller ，就算 user 和 order 单独拆成两个模块， order 模块依赖 user 模块，可能题主也不会觉得怪怪的了

再说说题主说的重复依赖，我个人觉得这个问题不大，只要不是相同包不同版本（这样可能有版本冲突），但只是重复依赖，还算好，毕竟都是分了父子模块，有父 pom 管理所有的版本，因此不同子模块引用相同的包也只会有相同的版本

如果确实觉得别扭，比如题主提到的情况，若 order 和 user 模块在去掉 controller 层下， order 和 user 都依赖了 jpa ， order 再依赖 user ，那我觉得 order 不依赖 jpa 也是可以的

最后题主提到有没有必要business模块按照业务拆分成子模块

这个就像刚才说一样，看你怎么拆，若是现在这样，一个 business 有不同的业务，业务之间有依赖，我觉得可行啊，因为在外看来， business 模块本身就是一个业务高内聚的模块，至于题主说觉得业务互相依赖，降低了 business 内每个业务的内聚性，但看你从哪个角度出发来看业务，如果整个 business 模块就是一个完整的大业务，那我觉得就是没有问题，很高内聚了，从需求来看， order 业务就是依赖 user 业务，真想要从这个粒度进行划分开，形成各自高内聚，那只能拆分不同服务，走微服务了，就算走子模块，你还是免不了模块的依赖（除非模块与模块之间本就变成了服务化），

但是如果需求变成，假设后续新出一个 web 项目，但是只是会用到 user 业务，那此时可以看到 business 模块的方式就不是很好，因为依赖了 business 模块，就会依赖到不会使用的 order 业务，但若按照业务拆分成 order 和 user 两个子模块，新的 web 项目就可以只依赖它需要的业务模块了，所以得看需求

综上，题主现在的设计基于现在的需求是可以的，没啥大问题，你要想去了解其他系统的设计，那你不光要看别人怎么做的，关键要看，它这样做到底是为了解决什么问题，单单看最终的做法然后借鉴到自己的项目上是不可取的，就像看一大堆设计模式，但是实际自己的代码根本就用不上，或者使用起来特别麻烦，还有一问题，那就是为了设计而设计，那就是过度设计了

当然肯想是很好的，这点题主还在上学就有这样的思考，已经很强了，要给个赞，不过以后实际工作开发还是要考虑我之前提到的几个条件，在几个条件的基础上再来好好设计，不能无脑一把梭。。。就像