设计领域模型以确保名称不重复

一些设计方法来实施不允许重复的业务规则。

问题

你在领域模型中有一个实体。这个实体有一个name属性。你需要确保这个名称在你的应用程序中是唯一的。你如何解决这个问题？这个仓库展示了在DDD应用中解决这个问题的11种不同方法，目标是将这个业务逻辑/规则保留在领域模型中。

方法

以下是解决这个问题的不同方法。在每种情况下，必要的类都被分组在一个文件夹中。想象一下，在真实的应用程序中，这些会被分割成几个项目，领域模型在一个项目中，仓储实现在另一个项目中，测试（或实际的UI客户端）在其他项目中。

数据库

最简单的方法是在你的领域模型中忽略这个规则（这在DDD中基本上是作弊），只依赖一些基础设施来为你处理它。通常这会采取在SQL数据库上设置唯一约束的形式，如果尝试在实体的表中插入或更新重复值，它会抛出异常。这种方法有效，但不允许改变持久化方式（改为不支持唯一约束或在成本或性能上不可接受的系统），也不能将业务规则保留在领域模型本身。然而，它也很简单并且性能良好，所以值得考虑。

这个仓库没有使用实际的数据库，所以这个行为是在ProductRepository中模拟的。

方法1 - 数据库

领域服务

一个选择是在领域服务中检测名称是否重复，并强制通过服务进行名称更新。这保持了逻辑在领域模型中，但导致了贫血实体。注意在这种方法中，实体本身没有逻辑，任何对实体的操作都需要通过领域服务进行。这种设计的一个问题是，随着时间的推移，它会导致将所有逻辑都放在服务中，并让服务直接操作实体，消除了实体中所有逻辑的封装。为什么会导致这种情况？因为领域模型的客户端想要一个一致的API来工作，他们不想有时使用实体上的方法，有时又通过服务使用方法，而且（从他们的角度来看）没有理由为什么需要使用其中一个或另一个。而且任何最初在实体上的方法，如果ever需要依赖，都可能需要移到服务中。

方法2 - 领域服务

将必要的数据传递给实体方法

一个选择是给实体方法提供它需要的所有数据来执行检查。在这种情况下，你需要传入一个列表，包含它应该不同于的每个名称。当然不要包括实体当前的名称，因为它自然可以是它已经是的名称。当你可能有数百万或更多实体时，这可能不太容易扩展。

方法3 - 将必要的数据传递给实体方法

将检查唯一性的服务传递给实体方法

使用这个选项，你通过方法注入执行依赖注入，并将必要的依赖传递给实体。不幸的是，这意味着调用者需要弄清楚如何获取这个依赖以调用方法。调用者也可能传入错误的服务，或者根本不传入服务，在这种情况下，领域规则将被绕过。

方法4 - 将服务传递给方法

将检查唯一性的函数传递给实体方法

这和前一个选项很像，但我们传递的是一个函数而不是一个类型。不幸的是，这个函数需要有所有必要的依赖和/或数据来执行工作，这些原本应该封装在实体方法中。在设计中也没有任何要求调用代码传入适当的函数，甚至任何有用的函数（可以很容易地提供一个无操作函数）。缺乏封装意味着业务规则的验证完全不是由我们的领域模型强制执行，而只是由客户端应用程序开发者的注意力和纪律性来保证（即使是你自己，也很容易忽视）。

方法5 - 将函数传递给方法

将过滤后的数据传递给实体方法

这是方法3的一个变体，其中调用代码现在只传递与提议名称匹配的现有名称，这样方法就可以确定新名称是否已经存在。对我来说，这似乎几乎做了业务规则所需的所有有用的工作，却没有真正进行唯一性检查。这对调用代码来说需要太多的工作和知识。

方法6 - 将过滤后的数据传递给方法

使用具有贫血子实体的聚合

问题没有提到这个实体是独立的还是聚合的一部分。如果我们引入一个聚合，我们可以通过使它负责所有名称的更改或添加来使它负责业务不变量（唯一名称）。让聚合负责其不变量，特别是当它们涉及子实体之间的关系时，通常是有意义的。然而，你要小心不要让你的聚合根变成一个上帝类，并把所有的子实体变成贫血的DTO（这种方法基本上就是这样做的）。

方法7 - 具有贫血子实体的聚合

使用带有双重分发的聚合

双重分发是一种模式，你将一个类的实例传递给一个方法，这样方法可以回调到这个实例。通常传递的是"当前实例"或this。它提供了一种方式，让聚合允许子实体保持对自己行为的责任，同时仍然可以回调到聚合以强制执行不变量。我倾向于在我的领域模型中保持单向关系，所以虽然从聚合到其子实体有一个导航属性，但反向没有。因此，要获得对聚合的引用，必须将一个引用传递给UpdateName方法。当然，这里没有什么可以强制实际传递预期的东西。调用代码可能传递null或聚合的新实例等。

方法8 - 带有双重分发的聚合

使用带有C#事件的聚合

这是第一个引入使用事件的选项。当你有需要响应某个动作的逻辑时，事件是有意义的。例如，"当有人试图重命名一个产品时，如果这个名称已经被使用，它应该抛出一个异常"。这种方法使用C#语言事件，不幸的是，正确实现需要大量代码。

方法9 - 带有C#事件的聚合

使用带有MediatR事件的聚合

这种方法使用聚合结合MediatR管理的事件。为了避免需要将MediatR传递给实体或其方法，我使用了一个静态辅助类。这是一种常见的方法，已经成功使用了十多年（参见2009年的领域事件救赎）。这种方法在API方面提供了最清晰的客户端体验之一。看看测试，注意每个测试都只是从仓储中获取聚合并调用一个方法。测试代码（在这种情况下模仿真实的客户端代码）不需要处理任何管道代码或传入函数或特殊服务或任何类似的东西。方法是干净的，API是干净的，业务逻辑在具有单一责任的特定类中得到执行。

方法10 - 带有MediatR事件的聚合

使用领域事件（无聚合）

有时涉及或建模聚合是没有意义的。在这种情况下，你仍然可以利用领域事件来提供一种方式，保持逻辑封装在实体中，同时仍然利用基础设施依赖。这种方法中的客户端体验与前一种方法非常相似，除了在添加新产品时需要更多的客户端逻辑。否则，客户端体验非常清晰和一致，不会被来自领域层的实现细节所污染。

方法11 - MediatR领域事件

我还有一篇文章介绍如何在你的ASP.NET Core应用中设置这个，使用MediatR实现即时领域事件救赎。

总结

在大多数涉及多个实体及其同级的业务规则的情况下，我发现引入聚合是有意义的。假设你选择聚合路线，要小心避免将所有逻辑放在根上并让子实体变得贫血。我在使用事件从子实体向聚合根通信方面取得了很好的成功（除了这个示例，还可以参见AggregateEvents）。

如果你没有聚合，或者只会有一个聚合并且它会包含数百万其他实体（这可能是不可行的），那么你仍然可以使用领域事件来强制执行集合的约束，如最后一个示例所示。使用领域事件，如最后几种方法所示，确实违反了显式依赖原则，但该原则主要适用于服务，而不是实体，在这种情况下，我认为利用领域事件提供干净的领域接口并保持逻辑封装在我的实体中的权衡是值得的。