最佳实践——在应用之间共享 Spring-boot Service 和 Repo 层代码

Posted 2023-02-26

【中文标题】最佳实践——在应用之间共享 Spring-boot Service 和 Repo 层代码

【英文标题】：Best practice- share Spring-boot Service and Repo layer code between applications

【发布时间】：2022-01-08 14:50:20

【问题描述】：

需要一些关于基于层模块化 Springboot 应用程序的经典需求的最佳实践建议。

一些背景信息：

少于 10 名开发人员的中小型 Spring Boot 项目 2 个不同的 Spring-boot 应用程序和共享 Service、Repo 层以及共享模型 采用具有完整模型/控制器/服务/每个 API 的存储库的微服务方法为时已晚。 目前只有一个 Web 应用程序公开了前端应用程序的 API。 要求是添加用于 B2B 集成的新 API 集，因此请求/响应格式将与现有 API 完全不同。即前端客户端的 /webapi/v1/orders 和 /b2b/v1/orders 将需要返回不同的响应格式。 Service 和 Repository 层以及模型需要在 2 个应用程序之间共享，因此 3 个模块被标识为类似于https://***.com/a/50352532/907032 中的解释

-- Main app   
   -- Webapi (Got dependency to common, jar packaging)
   -- b2b (Got dependency to common, jar packaging)
   -- common (jar packaging)

这两个应用需要单独部署，也需要从CICD的角度分离，不要每次都构建所有的子模块（b2b控制器的变化不应该影响common/Webapi） 只有最新的 b2b 模块才需要更改公共模块，最好不要触发 webapi 的构建和部署。即 webapi 使用 common-1.01 而 b2b 模块使用 common-1.02。了解新版本 common-1.02 不应破坏 common-1.01 的任何功能，而只是尝试为该模块保存不必要的构建和部署，直到需要时才有意义。

挑战

模块应该定义在同一个 Repo 还是 3 个不同的 Repos 中？ 所有关于单存储库与多存储库的讨论都是关于是否将所有不同的项目保留在同一项目中，但在这里您可以看到这些模块是相互关联的。 如果我们将它们定义为同一个 Repo 中的子模块，那么公共模块的版本控制如何处理？如果它总是触发所有三个子模块的构建，我们甚至有任何模块化代码的优势吗？

【参考方案1】：

根据您的描述，名为“common”的模块与其他两个模块并不常见。我会选择 the multi-modudle way 这样做：

首先将该通用模块分成三个：common、utils-webapi、utils-b2b

第一个将严格包含 webapi 和 b2b 在同一版本中需要的东西。 Utils-webapi 将严格专注于 api 中的内容。 utils-b2b 也是如此

B2b 依赖于 utils-b2b，而依赖于 common。 Webapi 依赖于 utils-webapi 和依赖于 common

通用模块的版本始终是一致的，从X模块的角度来看，只有utils-X模块版本发生变化

CI 因此对于每个构建都是独立的。

注意：您可以更进一步，简单地考虑 utils-webapi utils-b2b 并摆脱 common。以一些重复数据为代价。