首页 > 解决方案 > 如何在 DDD 架构中的书籍、视频、照片等不同资源之间创建通用关系表?

问题描述

我想知道如何在域设计项目(使用 NodeJS、NestJS)中制作类似非规范化通用关系表的东西。这些关系类似于社交媒体中的“喜欢”,可以应用于不同的项目类型,可能会跨越有界的上下文,但不需要了解上下文的域和内部逻辑。

在数据库方面,这是一个概念,但通常不是好的做法:

Table: Universal_Relationships

Rel_ID  |   Res_A_ID    |   Res_A_Type  |   Res_B_ID    |   Res_B_Type

12              23              2               344             6


Table: Resource_Types

Type_ID |   Type_Name

2           Map_Location
6           Research_Reference
8           Photo
10          Artwork
11          Video
12          Note
[…]

Table: Map_Locations

Place_ID    |   Marker_Title    |   Coord_X (or Lat)    |   Coord_Y (or Long)   |   Description

    2           Eugene                  44.064319           -123.0825664                City

Table: Research_Reference

Ref_ID  |   Title           |   Publisher       |   Abstract

    6       Tourist Guide       Collins             Guide to ...

非常感谢任何帮助,谢谢

标签: node.jsdomain-driven-designrelationship

解决方案


我建议将关系建模为聚合(不同类型的关系可能是不同的聚合,或者您可能只是将关系作为聚合);由于关系是不同有界上下文中聚合之间的事物之间的关系,因此这可能是它自己的有界上下文。

聚合基本上只是持有对相关聚合根的引用(通过 ID,而不是编程语言意义上的引用)(如果关系在可以关联的方面是自由形式的,那么这些 ID 也将编码总计的)。

值得注意的是,当我们跨越有界上下文(通常可以想象它们开始在彼此之间的网络距离处运行)时,某种程度的最终一致性很可能会发挥作用:我建议不要尝试强制执行强外部除非您绝对确定您永远不会在彼此之间的网络距离处运行有界上下文(并明确表示这种关系有界上下文将阻止这样做),否则对关系的键样式约束。


推荐阅读