外部id作为域标识

Question

我们的应用程序向与我们一起工作的第三方发送/接收大量数据。

我们的域模型主要是用这些数据填充的。

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

看来我们有三种选择：

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

关于外部ID：

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

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

我们应该选择哪种选择？

** 更新 **

也许我对“第三次派对”这个词不太清楚。

事实上，外部来源是我们的客户谁是活跃在汽车行业。

我们的应用程序使用客户端的主数据来完成几个“事情”。我们有几个有限的上下文(BC)，如“客户管理”、“调查”、“约会”、“维护”等。

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

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

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

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

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

总结一下：

• 任务有一个任务id
• 任务可能与多个BCs相关。
• 每个BC向客户端发送一些带有相关任务id的“结果消息”。
• 任务id按域事件分布。
• 我们让每一个(内部)持久化任务都是最新的。

希望我对外部id (= task-id)和我们不同的BCs的使用已经足够清楚了。

Answer 1

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

你换过第三方服务吗？

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

更新

根据新的信息，这听起来像一个correlationId。我会把它和其他与聚合有关的信息放在一起。

Answer 2

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

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

默认情况下:我将使用外部ID作为种子的一部分，获取一个基于名称的uuid，这提供了一个从外部到内部的简单映射。