Maven 架构选型，单模块还是多模块？
点击上方“芋道源码”，选择“设为星标”
管她前浪，还是后浪？
能浪的浪，才是好浪！
每天 10:33 更新文章，每天掉亿点点头发...
源码精品专栏
- 原创 | Java 2021 超神之路，很肝~
- 中文详细注释的开源项目
- RPC 框架 Dubbo 源码解析
- 网络应用框架 Netty 源码解析
- 消息中间件 RocketMQ 源码解析
- 数据库中间件 Sharding-JDBC 和 MyCAT 源码解析
- 作业调度中间件 Elastic-Job 源码解析
- 分布式事务中间件 TCC-Transaction 源码解析
- Eureka 和 Hystrix 源码解析
- Java 并发源码
来源：my.oschina.net/AmosWang /blog/4951326
1. 单模块
优势
快速上手，前期开发效率高。
劣势
要想实现传统的三层架构（web/service/dao），多采用分包，分包带来个问题就是，包之间边界约束不够。
正常来说，三层架构之间是有依赖关系的，dao --> service --> web，依赖是单向的。
举个例子：前端请求的 xxxRequest 应该放哪呢，放 web 还是 service，放 web 的话，service 应该是不能访问的，所以怎么约束呢？
再极端一点，dao 不能调用 service 吧，但项目中最不缺的就是临时方案，所以怎么约束呢？
推荐下自己做的 Spring Boot 的实战项目： https://github.com/YunaiV/ruoyi-vue-pro
2. 多模块（重点来了）
优势
约束能力，模块间引用关系是明确的，项目架构更清晰。
劣势
简单说，从头搭着可能慢点，用上模板都差不多。
首推阿里COLA：https://github.com/alibaba/COLA
本人结合 阿里COLA4.0 实现了一个，模块结构如下
think-cola
- start（启动项目）
- think-client（api、dto）
- think-controller（controller，调用app）
- think-app（校验、封装、执行，调用domain、infrastructure）
- think-domain（DDD 领域模型，也可暴露接口，由infrastructure实现）
- think-infrastructure（db、rpc、search、防腐）
项目地址：https://github.com/AmosWang0626/think-cola
推荐下自己做的 Spring Cloud 的实战项目： https://github.com/YunaiV/onemall
3. 怎么选？
作为应用级架构，小项目，2~3个人开发的，单模块可能就足够，前提是每个人都对架构有认识，个人约束力很重要；
其他均建议多模块，长期来看，约束是第一生产力，架构直接影响重构的成本。
引用《代码精进之路：从码农到工匠》中的两段话结尾：
- 要记住，留给公司一个方便维护、整洁优雅的代码库，是我们技术人员最高技术使命，也是我们对公司做出的最大技术贡献；
- 【防止破窗】首先我们要有一套规范，并尽量遵守规范，不要做“打破第一扇窗”的人；其次，发现“破窗”要及时修复，不要让问题进一步恶化。
欢迎加入我的知识星球，一起探讨架构，交流源码。加入方式，长按下方二维码噢：
已在知识星球更新源码解析如下：
最近更新《芋道 SpringBoot 2.X 入门》系列，已经 101 余篇，覆盖了 MyBatis、Redis、MongoDB、ES、分库分表、读写分离、SpringMVC、Webflux、权限、WebSocket、Dubbo、RabbitMQ、RocketMQ、Kafka、性能测试等等内容。
提供近 3W 行代码的 SpringBoot 示例，以及超 4W 行代码的电商微服务项目。
获取方式：点“在看”，关注公众号并回复 666 领取，更多内容陆续奉上。
文章有帮助的话，在看，转发吧。谢谢支持哟 (*^__^*）