JHipster 微服务实体

Question

我阅读了BFF pattern，我有一个疑问，如果一个微服务仅适用于 iOS，而另一个微服务仅适用于 Android，如果这两个服务使用相同的数据库和相同的表，必须如何创建实体？

我正在尝试使用 JDL-Studio 并使用 import-idl 命令导入模型，但我不知道该命令是否必须在每个微服务的工作区中运行

编辑：

关于更多上下文，我想构建一个完整的堆栈应用程序，该应用程序可以通过 REST 调用从网页、iOS 和 Android 应用程序中实现大量并发，我不知道在每个微服务中重复实体是否正确（为每个平台分离 API）或仅添加一个微服务作为数据库层。

编辑 2： 我发现这个 blog 谈论使用微服务创建 jhipster 应用程序，这个人展示了网关如何拥有自己的实体，而微服务也拥有自己的实体..

现在，我对微服务架构的真正基础有了更清楚的了解，但是如果我想要一个包含所有实体的微服务和只包含 UI 实体的网关怎么办？该博客展示了如何做到这一点，但只有一个实体，我有一个包含所有实体的完整 model.jhl

Answer 1

除了原始的主后端 API 应用程序之外，我不会对其中任何一个使用 import-idl。您不希望每个 BFF 都有一个完整的后端堆栈，否则您将不得不维护多个应用程序，其中大部分功能都在做同样的事情，而且您需要将这些数据源之间的数据同步为某种“掌握”。如果您将所有内容重新指向单个数据库并在 BFF 组件之间共享所有实体，那么它不适合微服务模型。

BFF 模式应该是现有服务 API 前面的一个薄外观，它过滤并可能在必要时调用多个服务 API 来聚合内容以适应每种客户端类型。当您无法控制现有 API 或增量服务分解中的（临时）步骤时，我认为这种模式更像是一种方便的创可贴。理想情况下，微服务不应该有这样的同步依赖，而且我不是水平分解的忠实粉丝。

在我看来，如果从头开始开发，没有复杂的架构和添加另一层间接层的延迟，那么有更好的方法来实现“BFF”功能。微服务架构经常被比作 UNIX 命令。当需要满足不同需求时，相同的 UNIX 命令能够提供更详细的信息。例如，将ls 的输出与ls -l 进行比较。这种策略也可以应用于单个微服务端点。