我想在这里询问以下情况。
假设我们有 2 个应用程序或"(微(服务"：
-
应用程序A位于大数据存储之上，并通过REST公开数据，它是典型的Spring Boot应用程序，需要管理权限，进行一些转换和映射等，并且它封装了必要的低级数据API，这是相当复杂的。
-
应用 B 的第二个职责是为特定域实现核心业务逻辑。此应用程序还具有其持久性层，即其自己的本地数据存储。但是，它也严重依赖于应用程序 A，因为应用程序 A 集中访问该大数据存储。
根据我的理解，我会说应用程序 A 和 B 是独立的应用程序/服务，每个应用程序/服务都专注于其任务。 然而，当有人会想到应用程序A实际上是应用程序B的"持久性层"的方式的A-B关系时，它会产生任何差异或不必要的后果，即与其"本地持久性逻辑"一起，因此是相同的模块。这可以被认为是实现 Dao 或存储库接口，一些 REST 实现在数据层/模块中调用应用程序 A。
在我看来，我宁愿将其视为典型的集成案例，并且我不会将本地持久性逻辑(自己的数据存储(与应用程序 B 提供的此委托数据 API 混合使用。我认为这是另一个常规服务，而不是位于 B 数据层中的应用程序 B 的"远程子模块"。
我希望上面的描述足以理解。目前，我想看看，这里的任何偏好是否意味着真实和相当不想要的后果，或者这只是个人品味的问题。
非常感谢任何评论。
这有点基于意见，因为没有"正确"和"错误"的方式来解决这个问题。 但是，架构问题经常出现这种情况，所以我会试一试。
对于您的方案，我会考虑三种路径：
- 如果
App A是保存所有或大多数服务的数据的单个存储库，则可能需要对其进行分解，以便在每个服务边界的域内移动持久性。 - 如果
App B是具有与App A密切相关的数据的特殊情况，并且两个服务都提供所需的功能(不重叠(，请考虑App B直接连接到数据库，并将这两个服务放在表示该特定域的外观后面。 - 如果
App B所做的只是为App A中的数据提供接口，那么你的服务边界可能画错了，两者可以/应该结合起来。
在客户端和数据持久性之间的链中添加额外的HTTP API调用(使用App B作为App A中数据的"接口"(将是保持性能的一大挑战，也是我要避免的。 如果经过仔细评估后，确定当前边界是最佳的，则可以研究一种更快或更同步的方式来与App A中的大数据存储进行通信，例如 gRPC 或类似内容。
让多个服务共享一个持久性层通常也是不可取的，但如果确实有多个不同的业务域在本质上相同的数据集上运行，那并非闻所未闻。 这可能有意义的一个示例是存储/管理地址的服务，以及使用同一数据存储的单独服务，该服务使用外部 API 验证地址。
服务边界应表示业务域边界，而这些边界很少(但并非从不！(包括单个大型数据存储。 因此，请专注于确保App A和App B根据其业务功能适当独立，您的答案可能会变得更加清晰。