在DDD中，实体具有唯一标识它们的值，即标识。有时此标识由服务器生成，有时从另一个 BC 获取，有时由用户提供，等等。假设我们正在用户提供标识的方案中工作。
假设有一个业务流程完全在纸上完成，并且不会很快迁移到计算机，其中流程所有者决定称为资源的东西的新名称。该名称始终遵循固定的架构(如PROD-<today's date>-<short random string>)，并且始终在非常重要的团队成员之间进行验证。选择和验证的名称是PROD-2021-01-04-KAH14564YUDO，最后一个字符是"O"(字母)而不是"0"(数字)。
假设操作员在系统中注册了这个新资源，提供了给定的标识，但错误地将最后一个字符拼写为零，可能是因为笔迹不好。插入实体，通过其标识链接到其他一些实体，然后有人检测到标识中的错误。现在应该怎么做？
我们知道实体的身份应该是唯一且不可变的，但在这里我们似乎需要纠正(并因此改变)它。引入代理身份以避免这种错误的插入问题是不正确的，因为由 PO 提供并由非常重要的团队成员验证的身份实际上是唯一的，不会更改，它只是在管理系统中插入错误;此外，在业务中没有与资源相关的替代身份的概念。
此方案中的错误在哪里？
有趣的情况。我假设您无法向Identity添加验证，因为它只是用户输入的随机字符串。
让我们从问题开始 在这种情况下错误在哪里？.这是您所在Domain中容易出错的机制或工作流程。当您为特定域构建系统时，您将不得不处理来自该域的讨厌的东西。你只需要尽早抓住这些讨厌的规则或机制，并以处理它们的方式设计系统。
让我们看看如何处理这种情况。
您可以做的一件事是使用系统使用且对用户隐藏的另一个 ID(例如自动生成的GUID)。您可以使用它将其他实体链接到此实体。这样，如果用户输入的Identity检测到错误，则不必更新整个系统，因为Identity不会在其他任何地方使用。如果您需要从系统的另一部分使用它，您应该只进行查询，其中包含获取Identity的GUID。这将不确定 ID 是否确实不可变。根据系统的不同，它可能是一个很好的解决方案，也可能使它的某些部分复杂化，并且并不总是一个可行的解决方案。
如果仅将另一个 ID 用于系统不是一种选择，那么您只需要以处理这些情况的方式设计它。您必须将更新用户的Identity作为用例。添加对使用此Identity的系统的每个部分的Identity更新的处理。在某些情况下，这些错误会产生令人讨厌的后果。例如，如果此Identity通过电子邮件发送到另一个系统或某个人，并且已在系统无法控制的其他位置使用。在这种情况下，这不是系统故障，而是Domain和使用它的人。解决此问题的唯一方法是 更改Domain中的规则和机制 .大多数时候这是不可能的，但有时您可以提出此问题，并且可以实施更强大的机制。这是一个令人讨厌的情况，但这就是生活。
使用natural keys/identity而不是 GUID 的示例。
如果您有一个与natural keys一起运行的系统网络，并且它们的生成是强大的，则可以使用它们。例如，银行系统使用国际银行帐号 (IBAN)。这些数字由可靠的特殊架构生成。它们不仅仅是用户输入的一些随机字符串。在这种情况下，域具有可靠的机制，可确保这些natural keys有效。在这种情况下，几乎不可能将 GUID 发送到另一个银行系统以交换 IBAN。
向银行账户汇款时，会验证此 IBAN，因此很容易检测到错误。这样，一个人就不能向不存在的银行账户汇款，因此只是因为打错字而失去钱。
如果您无法修复数据库，请修复纸张并确保它不再发生，例如仅使用十六进制字符。