database-design - 使用 Natural key 作为 DomainObject 的 ID 或 GUID + 自增域驱动设计

Question

我已经阅读了很多关于 DDD 的文章，并注意到大多数在持久化到数据库时都使用 GUID 作为他们的 ID。他们说 GUID 可以很好地扩展并且自动递增 ID 在可扩展性方面是一个很大的禁忌。

我现在很困惑是否使用GUID或 auto-increment .

基本上域是关于membership system (binary tree). (tracking of register members)
第一个要求是我们应该有一些东西可以在系统中唯一标识它们(我们称之为 Account No.)，也许是 7digit。

接新Members可以被其他人注册 Member .我们称之为转介。

现在我打算做的是拥有 MemberId GUID 类型作为 DomainObject Id，它用作主键，用于连接、外键(在 Referral 上，referer_id 将是 GUID MemberId)。 AccountNo将是一个自动增量列，或者它可能会通过 MAX() + 1 从存储库中获取。主要用于系统和链接中的搜索功能。

DomainObject 的 ID 是否应该对系统用户隐藏，因为它只是一个技术实现？

两者结合可以吗？ GUID 作为数据库中的 row_id(代理键)。和(自然键)的自动增量？

可以排除AccountNo吗？来自构造函数，因为它无论如何都会自动递增？那么需要强制执行不变量呢？所以从存储库获取下一个 ID 是要走的路，包括 AccountNo在构造函数中？

我应该坚持使用自动递增 ID 而忘记 GUID，删除 MemberId并让 AccountNo是DomainObject 的ID？

笔记:

我不是在构建某种类型的下一个 facebook。

我只想练习 DDD 的战术方面，以了解如何在了解其优缺点的情况下做出艰难的架构决策。

我只想练习 DDD 的战略方面，以了解如何在了解其优缺点及其实现的情况下做出艰难的架构决策。

如果我们将成员(member)注册分为3个场景:

第一个场景:成员(member)注册每分钟发生一次。

第二个场景:成员(member)注册每小时发生一次。

第三个场景:成员(member)注册每天最多发生5次。

它将如何影响决策？

技术栈:

ASP MVC 5

SQL Server 2014

C#

小巧玲珑的 ORM

Answer 1

很可能你的问题太多了，无法给你一个完整的答案，因为ID设计并不简单，而且有很多方面。我可以推荐 Vaughn Vernon 的书“Implementing DDD”，它有一节专门介绍身份设计(第 5 章“实体” - 唯一身份)。

无论如何，我都会尝试为您指明正确的方向，而不是背诵该章节中的所有内容:-)。

你需要什么？

您已经提出了一些有关 ID 设计的问题，但您还需要提出更多问题。只有这样，您才能决定 GUID、DB 生成的 ID 还是不同的 ID 是否合适。

ID 的域意义是什么？可能 ID 只是为了促进技术解决方案而存在，但根本不是域的一部分？

谁提供身份证？这可以是用户、应用程序、数据库，甚至是另一个限界上下文。

什么时候需要身份证？在创建关联实体之前，在创建时，还是仅在实体持久化时？

这些问题的答案将限制您可以使用的 ID 生成类型。

你应该注意什么

关于 ID 设计有一些规则。强烈建议您遵循它们，以免以后用脚射击:

确保您的 ID 是唯一的。对于用户提供的 ID，这可能尤其令人担忧。您需要强制执行唯一性并让您的用户有可能检测现有 ID。对于应用程序生成的随机 ID 或数据库生成的 ID，这通常不是问题。

确保您的 ID 是稳定的。永远不要更改实体的 ID!毕竟，ID 是您用来引用实体的东西。这样做的结果是，您不应将可能更改的内容作为 ID 的一部分。例如。一个人的姓氏可能不是一个好的选择，因为当有人结婚时这可能会改变(并且可能因为非唯一性而有问题)。

如果 ID 只是一个技术概念，请隐藏它们。从 DDD 的角度来看，将技术概念作为域模型的一部分是错误的。

例子

以下是如何找到 ID 设计的示例:

允许延迟创建 ID(即通过持久性)意味着您在创建实体时确实有一个没有 ID 的实体。因此，如果您需要早期或即时 ID，则不能使用 DB 生成的 ID(除非您接受仅为 ID 检索而联系 DB)。

然后你可能决定用户对 ID 不感兴趣，所以必须指定 ID 会很奇怪。这留下了应用程序生成的 ID。

对于应用程序生成的 ID，您需要确保 ID 是唯一的。这对于单实例应用程序来说是微不足道的，但是一旦您使用多个应用程序实例创建负载平衡设置，这可能会带来更多问题。这就是为什么许多人首先使用随机 ID(例如 GUID)的原因，因此他们在横向扩展时不会陷入死胡同。

如您所见，这个例子做了很多假设。没有对错之分，但是通过上述问题，您应该能够做出明智的决定。