Domain driven design 作为域标识的外部id

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

我们面临的“问题”是确定一个“好”候选人作为聚合的域标识

我们似乎有3种选择：

生成域标识（

UUID

或

DB序列

…）

使用外部ID作为域标识，它与来自外部源的所有数据一起提供

使用内部域标识和外部标识作为单独的标识“可能”用于检索操作；内部id始终为前导

关于外部ID：

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

特别是上面的最后一点让我们确信，外部id不是一个基础设施问题，而是真正属于这个领域

我们应该选择哪种选择

**更新**

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

我们的客户向我们发送“任务”，描述需要完成的事情。 “某物”可能是：

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

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

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

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

总结一下：

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

---

希望我对外部id（=任务id）的使用和我们不同的BCs已经足够清楚了。

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

你会切换第三方服务吗

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

[更新]

---

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

一般来说，我会否决使用DB序列号作为标识符；域模型应该独立于持久性的选择；域模型将标识符写入数据库，而不是以相反的方式写入（如果DB希望出于自身目的跟踪序列号，则可以）

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

我的默认设置是：我将使用外部ID作为种子的一部分，从而实现从外部到内部的简单映射