外部ID作为域标识

Question

我们的应用程序向与我们合作的第三方发送/接收大量数据 我们的域模型主要包含该数据。

我们遇到的“问题”是将“好”候选人识别为聚合的域名标识。

似乎我们有3个选择：

1. 生成域名标识（UUID或DB-sequence ...）;
2. 使用外部ID作为域标识，它附带来自外部源的所有数据。
3. 使用内部域标识和外部标识作为单独的标识，“可能”用于检索操作;内部ID总是领先

关于外部ID：

• 100％保证ID 永不改变
• 外部来源
始终托管 系统中的
• 其他域可能会使用external-id 进行检索操作

特别是上面的最后一点使我们确信外部身份不是基础设施问题，而是真正属于域名。

我们应该选择哪个选项？

** 更新 **

也许我不清楚“第三方”一词 实际上，外部资源是我们在汽车行业活跃的客户。
我们的应用程序使用客户的主数据来完成几个“事物”。我们有几个有界上下文（BC），如'客户管理'，'调查'，'约会'， '维护'等。

我们的客户向我们发送了描述某些需要完成的“任务”。 那'某事'可能是：

• '让客户X完成调查Y'
• '安排/取消客户X'的预约
• '客户Y的车X计划在位置XYZ'
维修

这些'任务'总是有'task-id'，保证是唯一的。 我们将所有传入的“任务”存储在我们的数据库中（活动记录样式）。任务上的每个可能操作都映射到域事件。 （多个BC可能对同一任务感兴趣）

每个BC包含一个或多个聚合，这些聚合将一些域事件分发给其他BC。例如，当取消约会时会触发域事件，维护会监听该事件以完成某些操作。


但是，我们的客户端在每个与任务相关的操作后都会收到一些消息。因此，我们总是需要使用'task-id'。

总结一下：

• 任务有一个任务ID
• 任务可能与多个BC相关
• 每个BC使用相关的task-id
向客户端发送一些“结果消息”
• 任务ID由域事件分发
• 我们将每个（内部）持久性任务保持最新


希望我对使用external-id（= task-id）和我们不同的BC很清楚。

Answer 1

我的直觉是管理自己的身份，而不是依靠第三方服务，所以上面的选项3。虽然没有上下文很难说。什么是第三方系统？你的域名是什么？

您是否会切换第三方服务？

您说域名的其他部分可能会使用外部ID进行查询 - 他们查询的内容是什么？您的内部系统或第三方服务？

[更新]

根据新信息，它听起来像是correlationId。我将它与其他与聚合相关的信息一起存储。

Answer 2

作为一般规则，我会否决使用DB序列号作为标识符;域模型应该独立于持久性的选择;域模型将标识符写入数据库，而不是相反（如果数据库想要为了自己的目的跟踪序列号，那很好）。

我不愿意使用外部标识符，尽管在某些情况下它是有意义的。给定实体（如“客户”）可能在许多不同的有界上下文中具有表示形式 - 对所有这些实体使用相同的标识符可能是有意义的。

我的默认值：我会使用外部ID作为种子的一部分来达到name based uuid，这提供了从外部到内部的简单映射。