1

在 DDD 中，实体具有唯一标识它们的值，即标识。有时这个身份是由服务器生成的，有时是从另一个 BC 获得的，有时是由用户提供的，等等。假设我们在用户提供身份的场景中工作。

让我们假设有一个业务流程专门在纸上完成并且不会很快迁移到计算机，流程所有者决定了一个称为资源的事物的新名称。该名称始终遵循固定模式PROD-<today's date>-<short random string>，并且始终在非常重要的团队成员之间进行验证。选择和验证的名称是PROD-2021-01-04-KAH14564YUDO，最后一个字符是“O”（字母）而不是“0”（数字）。

假设操作员在系统中注册了这个新资源，提供了给定的身份，但错误地将最后一个字符拼成了零，可能是因为笔迹不好。实体被插入，其他一些实体通过其身份链接到它，然后有人检测到身份中的错误。现在应该怎么办？

我们知道 Entity 的身份应该是唯一且不可变的，但在这里似乎我们需要更正（并因此更改）它。引入代理身份来避免这种错误的插入问题是不正确的，因为由 PO 提供并由非常重要的团队成员验证的身份实际上是唯一的并且不能更改，它只是在管理系统中插入错误；此外，在业务中没有与资源相关的代理身份的概念。

这种情况下的错误在哪里？

4

2 回答 2

0

有趣的情况。我假设您不能向 中添加验证，Identity因为它只是用户输入的随机字符串。

让我们从这个问题开始，这个场景中的错误在哪里？. 这是您所处的一个容易出错的机制或工作流程Domain。当您为特定域构建系统时，您将不得不处理来自该域的讨厌的东西。你只需要尽早发现这些讨厌的规则或机制，并以一种处理它们的方式设计系统。

让我们看看如何处理这种情况。

GUID您可以做的一件事是使用系统使用且对用户隐藏的另一个 ID（例如自动生成的）。您可以使用它将其他实体链接到此实体。这样，如果检测到Identity用户输入的错误，您就不必更新整个系统，因为它Identity不会在其他任何地方使用。如果您需要从系统的另一部分获取它，您只需查询包含 的GUID即可Identity。这将不确定 ID 确实是不可变的。根据系统的不同，它可能是一个很好的解决方案，或者它可能会使某些部分复杂化，并且并不总是一个可行的解决方案。

如果无法选择仅将另一个 ID 用于系统使用，那么您只需设计它以处理这些情况。您必须将Identity来自用户的更新作为用例包括在内。添加处理Identity来自使用它的系统的每个部分的更新Identity。在某些情况下，这些错误会产生令人讨厌的后果。一个例子是，如果这Identity是通过电子邮件发送到另一个系统或某人，并且已经在您的系统无法控制的其他地方使用。在这种情况下，这不是系统故障，而是在Domain使用它的人和使用它的人身上。解决这个问题的唯一方法是改变规则和机制Domain. 大多数情况下这是不可能的，但有时您可以提出这个问题，并且可以实施更强大的机制。这是一个令人讨厌的情况，但这就是生活。

使用natural keys/identity代替 GUID 的示例。

如果您有一个可以运行的系统网络natural keys并且它们的生成功能强大，那么您可以使用它们。例如，银行系统使用国际银行帐号 ( IBAN )。这些数字是由一个健壮的特殊模式生成的。它们不仅仅是用户输入的一些随机字符串。在这种情况下，域有一个强大的机制来确保这些natural keys是有效的。在这种情况下，几乎不可能将 GUID 发送到另一个银行系统来交换 IBAN。

向银行账户汇款时，此 IBAN 会经过验证，因此很容易检测到错误。这样，一个人就无法将钱汇到一个不存在的银行账户，从而仅仅因为打错而失去了他们。

于 2021-01-10T14:38:11.910 回答
0

如果您无法修复数据库，请修复纸张并确保它不再发生，例如仅使用十六进制字符。

于 2021-01-15T18:19:17.290 回答