Spring Boot多模块划分设计
在Spring Boot多模块项目中，模块划分主要有两种思路：技术分层划分和业务功能划分。两种方式各有优缺点，需要根据项目规模、团队结构和业务特点来选择。
1. 技术分层划分（横向拆分）
结构示例：
project-root
├── pom.xml
├── module-common // 公共模块
├── module-domain // 实体类、DTO、枚举等
├── module-dao // Mapper/Repository
├── module-service // 业务逻辑
├── module-api // Controller层
└── module-web // 前端资源/配置
优点：
- 职责清晰：每个模块职责单一，符合单一职责原则。
- 复用性强：公共模块（如工具类、通用配置）可被其他模块依赖。
- 适合技术架构明确的场景：如需要严格分层（如DDD中的分层架构）。
缺点：
- 业务逻辑分散：修改一个业务功能可能需要跨多个模块（如改实体类+Service+Controller）。
- 模块依赖复杂：容易形成环形依赖（如Service依赖Dao，Dao又依赖Domain）。
- 不适合复杂业务：业务扩展时模块间协调成本高。
2. 业务功能划分（纵向拆分）
结构示例：
project-root
├── pom.xml
├── module-common // 公共模块
├── module-user // 用户相关功能
│ ├── domain // 用户实体类
│ ├── dao // 用户Mapper
│ ├── service // 用户Service
│ └── controller // 用户API
├── module-order // 订单相关功能
│ ├── domain // 订单实体类
│ ├── dao // 订单Mapper
│ ├── service // 订单Service
│ └── controller // 订单API
└── module-payment // 支付相关功能
优点：
-
高内聚低耦合：每个业务模块自包含，修改时只需关注当前模块。
-
独立性强：模块可单独开发、测试、部署，甚至拆分为微服务。
-
适合业务复杂场景：如电商系统（订单、支付、库存等业务明确分离）。
缺点：
- 重复代码风险：不同模块可能出现相似的实体或工具类（需通过common模块解决）。
- 初期设计成本高：需要明确业务边界，否则后期拆分困难。
如何选择？
| 场景 | 推荐划分方式 |
|---|---|
| 小型项目或技术验证项目 | 技术分层划分 |
| 严格分层架构（如DDD） | 技术分层划分 |
| 中大型复杂业务系统 | 业务功能划分 |
| 未来可能拆分为微服务 | 业务功能划分 |