domain-driven-design - 外部 id 作为域标识

Question

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

我们遇到的“问题”是确定一个“好的”候选者作为聚合的域标识。

看来我们有 3 个选择:

1. 生成域标识(UUID 或DB-sequence...)；
2. 使用外部 ID 作为域标识，它与来自外部源的所有数据一起出现。
3. 使用内部域身份和外部 ID 作为单独的 ID，“可能”用于检索操作；内部 id 总是领先

关于外部 ID:

• 100% 保证 ID 永远不会更改
• ID 始终由外部来源管理
我们系统中的
• 其他域可能会使用external-id进行检索操作

特别是上面的最后一点让我们相信，external-id 不是基础设施问题，而是真正属于域。

我们应该选择哪个选项？

** 更新 **

可能我对“第三者”这个词不是很清楚。
实际上，外部来源是我们活跃于汽车行业的客户。
我们的应用程序使用客户的主数据来完成几件“事情”。我们有几个限界上下文 (BC)，例如“客户管理”、“调查”、“约会”、“维护”等

我们的客户向我们发送了描述某事需要完成的“任务”。那个“东西”可能是:

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

那些“任务”总是有一个保证唯一的“任务 ID”。我们将所有传入的“任务”存储在我们的数据库中(事件记录样式)。任务映射上的每个可能操作都与域事件对应。 (多个 BC 可能对同一个任务感兴趣)

每个 BC 包含一个或多个聚合，这些聚合将一些领域事件分发给其他 BC。例如，当一个约会被取消时，一个域事件被触发，维护监听那个事件来完成一些事情。

但是，我们的客户希望在与任务相关的每个操作之后都有一些消息。因此，我们始终需要使用“任务 ID”。

总结一下:

• 任务有一个task-id
• 任务可能与多个 BC 相关
• 每个 BC 都会向客户端发送一些带有相关任务 ID 的“结果消息”
• 任务 ID 按领域事件分发
• 我们保持每个(内部)持久化任务的最新状态

希望我对外部 ID(= 任务 ID)的使用和我们不同的 BC 足够清楚。

Answer 1

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

您会更换第 3 方服务吗？

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

[更新]

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