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