Spring Boot多应用共享Service、Repo层代码落地最佳实践咨询

针对小于10人的中小规模Spring Boot项目团队，结合你的模块关联度和构建部署需求，推荐单仓库 + 多构建模块 + 路径过滤CI + 独立版本发布的落地方案，比拆分独立仓库更适配你的场景，以下是具体问题的解答：

1. 仓库选型结论 #

优先选择单仓库管理3个模块，不需要拆分3个独立仓库：

• 小团队拆分多仓库会额外增加跨仓库代码同步、版本对齐、权限管理的冗余成本，你们模块关联性强，日常修改common后经常需要同步调整b2b或webapi的调用逻辑，单仓库可实现一次提交完成全链路修改，避免多仓库提PR、核对版本的繁琐流程
• 单仓库完全可以满足你要求的独立构建、common多版本复用的需求，不需要通过拆分仓库实现

2. 关联性强的模块选型判断标准 #

针对关联度高的模块，不需要照搬完全独立项目的选型逻辑，只要符合以下两个特征就选单仓库：

• 多个模块的维护团队没有完全拆分，大概率是同一批开发人员维护3个模块
• 日常迭代中经常需要跨模块修改代码，比如调整common的公共逻辑后需要同步验证两个业务模块的兼容性
  如果后续团队扩张，两个业务模块拆分给不同团队维护、迭代节奏完全独立，再拆分独立仓库也不会有额外重构成本。

3. 单仓库下的落地实现方案 #

3.1 如何避免全量构建 #

主流CI工具（GitLab CI、GitHub Actions、Jenkins）都支持路径过滤规则，直接在CI配置中添加规则即可：

• 仅b2b/目录下文件变更：只触发b2b模块的构建、部署流程
• 仅webapi/目录下文件变更：只触发webapi模块的构建、部署流程
• 仅common/目录下文件变更：只构建common模块，发布新版本到私有Maven仓库，不自动触发两个业务模块的构建
  完全可以实现你要求的局部变更只构建对应模块的需求。

3.2 如何处理common模块的版本控制 #

common模块使用独立的版本号管理，每次修改common后发布对应版本到私有Maven仓库（小团队搭Nexus即可，成本很低），webapi和b2b的构建配置（pom.xml/build.gradle）中各自声明依赖的common版本：

• b2b需要common新增能力时，主动把依赖的common版本升到最新版即可
• webapi不需要升级就保持原有common版本不变，两个业务模块可以完全独立使用不同版本的common，符合你要求的节省不必要构建部署成本的需求。

3.3 模块化的实际价值 #

你规划的三模块结构的收益和是否全量构建没有关系，核心价值体现在：

• 代码复用：公共Service、Repo、模型只需要维护一份，避免两份逻辑重复、数据不一致的问题
• 迭代隔离：两个业务模块的接口层代码完全拆分，不会出现修改B2B接口逻辑不小心影响前端API的问题
• 部署灵活：两个应用可以独立扩缩容，比如B2B调用量突增时只需要扩容b2b节点，不需要调整webapi的部署
• 扩展性强：后续如果业务扩张要拆分微服务、拆分维护团队，直接把对应模块拆成独立仓库即可，不需要重构代码结构

内容的提问来源于stack exchange，提问作者Sudarsan