在微服务架构中共享属性的模型实体

Question

问题陈述

在现实世界中，我们有实体资产（图像、视频、文档）和集合（一组资产）。现在，这两个实体都可以拥有类别（以及更多共享属性）。

我们不确定如何建模。

这是当前的方法：

A) 在

AssetService

中，

Asset

实体可以有1:n个类别。对于这个问题，一个

CategoryService

有一个

Asset

投影，一个

Category

实体和一个关系表

AssetCategory

。到目前为止，一切都很好。但是现在，我们发现另一个实体 (

Collections

) 也可以有 1:n

Categories

。 我们如何建模多个实体可以有一个类别？。其实我们也关心：

• 未来更多实体（如资产和收藏）可以有类别。
• 未来更多实体（如类别）可以被其他实体共享。

解决方案

B) 我们可以将

Category

投射到具有

Category

.

的其他服务中

Pro：看起来很干净，只有一个共享的类别实体

缺点：资产或集合与类别的关系被移动到 AssetService/CollectionService 的有界上下文

C) 我们还可以为所有具有

Category

的实体创建某种“聚合”，并将它们合并到一个服务中，并将其用作对

CategoryService

的投影。

亲：服务

Asset

、

Collection

和

Category

本身就很简单

缺点：对于每个即将到来的新实体和共享事物的组合，我们需要一个专用的聚合

D) 我们可以将两个投影移动到 CategoryService 并将类别与两者相关联。

Pro: Asset 和 Collection 服务相当干净

缺点：如果更多的实体有类别，那么很多预测都在类别服务中

E) 我们当然也可以为

Category

和

Asset

创建一个单独的

Collection

实体，但从用户的角度来看它们实际上是相同的

Category

。所以，会有很多没有真正原因的镜像。

不需要 E) 的图表

边注

• 我们期待
  • 100 Mio 资产
  • 10 个 Mio 类别
  • 10 个 Mio 系列
• 常见的读取查询（例如，“给我类别 x 的所有资产和集合”）将使用 Elastic Search 等非规范化数据源进行处理