针对不同类型实体的微服务设计

Question

我只想对如何为以下用例设计/编写微服务有一个高级的想法：

客户端 Microservice MediaStore（我们称它为 A）与另外两个不同的微服务通信

1. 微服务电影（B）
2. 微服务书（C）

用户可能想要从 MediaStore 查看/订购电影或书籍。 我知道 Movie 微服务将拥有其 Movie 实体和 MovieDB，同样，Book 微服务将拥有其 Book 实体和 BookDB。 由于用户可以订购，因此在 MediaStore 微服务端有一个“订购”实体。

但是如何在客户端 MediaStore 微服务上设计/编写/使用它们呢？

a) 我是否应该使用另一个通用实体（比如说 Item）作为电影和书籍的父接口，以便我可以与通用实体（Item）进行交互？ 原因是，我想在 MediaStore 微服务中创建一个实体“订单”。 订单可以是电影或书籍。

b）或者我应该将它们单独用作电影和书籍实体吗？ 从而在 MediaStore 微服务中创建 MovieOrder 和 BookOrder 作为订单。

c) 如果我能从 StackOverflow 社区获得有关此用例的任何其他建议/知识/提示，那将非常有帮助。 :)

Answer 1

如果这些实体（电影和书籍）之间有不同的属性，我想是这样，微服务 A 必须管理两个不同的实体，所以你应该选择 B 选项。

使用这种方法，您的订单实体将包含一个项目列表，并且一个项目必须存储项目类型，以便您可以将其转换为原始实体以获取其特定信息

Answer 2

DDD 的主要部分是识别定义何时发生变化（这些变化描绘了有界上下文）。 让您的微/宏服务（为此，宏服务是一个碰巧部署为协作微服务的单一服务）保持在一个有界上下文中通常是一个好主意。

因此，考虑到这一点，您可能需要考虑 MediaStore 的用途。 如果它的目的只是为了管理订单，那么书和电影真的有区别吗？ 如果没有，那么在 MediaStore 的上下文中，您所需要的只是“项目”，并且可以有一个属性说“这是一本书还是一部电影”。 它不会有任何特定于书籍或电影的内容：诸如作者、明星、导演等将是书籍和电影实体的属性，它们将具有一个属性（或者甚至可能是零个或一个，或者一个或多个，或零个或多个：考虑如何处理不出售/预订的书籍或电影，或者具有许多不同版本的书籍或电影......）将它们链接到项目。 然后，您将拥有书籍/电影服务来管理特定于书籍/电影的信息。