如何定义报告微服务的边界？答案

【问题标题】：How to define boundaries of a reporting microservice?如何定义报告微服务的边界？
【发布时间】：2021-04-13 18:50:41
【问题描述】：

假设我有一个Order Service，它提供了一个用于创建、更新和取消订单的 API。用户必须能够在必要时生成包含订单详细信息的 PDF。

我并不特别喜欢 Order Service 包含生成此 PDF 的必要逻辑（和所有依赖项），因为如果我需要在系统的更多部分实现 PDF 生成，我将不得不加载大量对每个微服务的依赖，此外似乎微服务的职责比它应该承担的要多。

但另一方面，如果我创建 Reporting Service 来生成这些 PDF，我会考虑到技术问题，此外，每个服务都必须发送数据、模板和 @987654324 的设置@ 并通过网络接收生成的 PDF 文件，这可能是一个瓶颈。

考虑到 Chris Richardson 在《微服务模式》一书中所说的：

微服务应该围绕业务问题进行组织，而不是技术问题

如何在不违反限界上下文和保持关注点分离的情况下进行设计？

【问题讨论】：

【解决方案1】：

最好在库中编写生成 PDF 的逻辑，并在所需的微服务中使用该库。

为 PDF 生成开发单独的微服务不是一个好的选择，因为 PDF 生成依赖于 (1.) 来自另一个微服务的数据和 (2.) 将数据转换为 PDF 的模板。所以，会有很多数据流。

【讨论】：

这似乎也不是一个好的选择。这种共享库的新版本将影响所有服务并使部署复杂化。结果是在某些时候没有人相信自己会开发公共共享库的下一个版本，因为它会影响许多服务。
我同意，共享库在部署或 DevOps 方面增加了复杂性。对于微服务架构风格来说，这并不总是一个好的选择。但在某些情况下，我们可以选择这个选项。我觉得您可以尝试特定于 PDF 案例的库选项。

【解决方案2】：

PDF 渲染与任何其他视图层关注点没有什么不同。以与将订单呈现到网页时使用的相同的粒度/分隔来封装它。

由于您可能不会在订单服务中处理订单的 HTML/JS 呈现，因此您可能也不想在那里处理订单的呈现。将您的 PDF 呈现保存在知道如何呈现它们的专用服务中，并将所需的数据传递给它。尽管订单服务可能不会调用此服务，但它可能会调用订单服务。

【讨论】：