外部 id 作为域身份

Question

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

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

我们似乎有 3 个选项：

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

关于外部 ID：

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

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

我们应该选择哪个选项？

** 更新 **

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

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

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

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

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

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

总结一下：

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

希望我对 external-id (= task-id) 和我们不同的 BC 的使用足够清楚。

Answer 1

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

你会切换 3rd 方服务吗？

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

[更新]

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

Answer 2

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

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

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