DDD中的例外

我正在学习DDD，并且正在考虑在某些情况下引发异常。我知道对象不能进入错误状态，因此这里的异常很好，但是在许多示例中，例如，如果我们尝试使用数据库中存在的电子邮件添加新用户，也会抛出异常。

public function doIt(UserData $userData)
{
    $user = $this->userRepository->byEmail($userData->email());
    if ($user) {
        throw new UserAlreadyExistsException();
    }

    $this->userRepository->add(
        new User(
            $userData->email(),
            $userData->password()
        )
    );
}

因此，如果存在使用此电子邮件的用户，那么我们可以在应用程序服务中捕获异常，但我们不应该使用try-catch块来控制应用程序的操作。

最好的方法是什么？

让我们从对问题空间的简短回顾开始：DDD的基本原则之一是将业务规则尽可能地靠近需要执行的地方。这是一个非常重要的概念，因为它使您的系统更具“凝聚力”。通常，将规则“向上”移动是贫血模型的标志。其中对象只是数据包，规则将与要执行的数据一起注入。

贫瘠的模型对于从DDD开始的开发人员来说可能很有意义。您将创建一个User模型，模型EmailMustBeUnqiueRule将注入必要的信息以验证电子邮件。简单。优雅。问题在于这种“种类”的思考本质上是程序性的。不是DDD。最终发生的事情是，您留下了一个模块，其中包含数十个经过Rules巧妙包装和封装的模块，但是它们完全缺少上下文，无法更改它们，因为不清楚何时何地执行它们。那有意义吗？这可能是不言而喻的，一个 EmailMustBeUnqiueRule将在创建的应用User，但怎么样UserIsInGoodStandingRule？慢慢但可以肯定的是，提取Rules脱离他们的上下文会使您拥有一个难以理解的系统（因此无法更改）。仅当实际处理/执行太冗长以致于您的模型开始失去焦点时，才应封装规则。

现在转到您的特定问题：使用Service/ CommandHandler引发问题Exception是您的业务逻辑开始泄漏（“向上”）到您的域之外。为什么您Service/ CommandHandler需要知道电子邮件必须是唯一的？应用程序服务层通常用于协调而非实现。如果我们ChangeEmail向您的系统添加方法/命令，就可以简单地说明其原因。现在，这两种方法/命令处理程序都需要包含唯一检查。这是开发人员可能会试图“提取”的地方EmailMustBeUniqueRule。如上所述，我们不想走那条路。

一些其他的知识紧缩可以使我们得到更多的DDD答案。电子邮件的唯一性是一个不变性，必须在一组User对象之间强制实施。您的域中是否存在一个表示“ User对象集合”的概念？我想您可能可以看到我要去的地方。

对于这种特殊情况（以及更多涉及在集合中强制执行不变式的情况），实现此逻辑的最佳位置将在您的中Repository。这特别方便，因为您Repository还“知道”执行这种验证所需的额外基础结构（数据存储）。在您的情况下，我会将此检查放在add方法中。这有道理吧？从概念上讲，正是这种方法真正User为您的系统添加了一个。数据存储是实现细节。

您可以在应用程序的每一层中进行验证。在何处强加哪些规则取决于您的应用程序。

例如，实体实现代表业务规则的方法，而用例实现特定于您的应用程序的规则。

如果您要构建类似Gmail的电子邮件服务，则可以说“用户应具有唯一的电子邮件地址”是一项业务规则。

如果您为新的CRM系统构建注册流程，则此规则可能最好在用例中实施，因为该规则也可能是用例的一部分。此外，由于您可以在用例测试中轻松对存储库调用进行存根，因此它也可能更易于测试。

为了实现额外的安全性，您还可以在存储库中强制执行此规则。