领域驱动设计中的领域事件是否隐藏了意图？答案

【问题标题】：Do Domain Events in Domain Driven Design hide the intent?领域驱动设计中的领域事件是否隐藏了意图？
【发布时间】：2013-04-25 16:08:14
【问题描述】：

使用领域事件是 DDD 应用程序广泛认可的做法，但有些场景对我来说很棘手。

我最近正在开发一个应用程序，其中业务逻辑要求在创建新用户时，该用户也在三个独立的子系统中创建。所以基本上如果你使用事务脚本方法，它看起来像：

public void CreateUser()
{
    CreateUserInSystemA();
    CreateUserInSystemB();
    CreateUserInSystemC();
}

我正在研究的方法是使用领域事件，所以入口点看起来像：

public void CreateUser()
{
    CreateUserInSystemA();
}

然后CreateUserInSystemA 将在创建用户时引发域事件。然后该事件的处理程序将在系统 B 中创建用户，引发另一个域事件，然后另一个处理程序将运行，它将在系统 C 中创建用户。所有这些都是在 DI 容器注册期间设置的，所以这几乎是硬连线的。

所以问题是：

1) 这种方法不是有效地隐藏了领域逻辑吗？通过查看 CreateUser 方法来了解我们真正在做什么并不容易。

2) 如果（就像我们的例子中发生的那样），您将有一个新的工作流程，您只需要在系统 A 和 B 中创建用户 - 因此不应调用CreateUserInSystemC？如果我们使用现有的CreateUserInSystemB 实现，它将引发域事件，并且硬连线的CreateUserInSystemC 无论如何都会运行。

以正确的 DDD 方式处理这种情况的最佳方法是什么？我们是否应该使用应用服务层并简单地为两个工作流公开两个单独的方法，而不是基于领域事件的流程？

【问题讨论】：

标签： domain-driven-design

【解决方案1】：

对我来说，域本身就是一个子系统。在您的情况下，您有多个互连的系统。在这种情况下，您的事件是系统间事件，而不是域事件。

因此，根据子系统之间的关系触发事件。从每个领域（子系统）的角度来看，其他子系统都是集成层，内部可能有自己的领域模型。

因此，您的问题的答案是：

1) 不，因为该方法与系统集成完全相关。

2) 流程更改需要更改集成行为，而不是子系统。

还有一点：我所说的子系统与服务类似。每个域都有与之交互的服务。并且服务通常与交互相关联（具有多个服务的 SOA 系统就是一个实现示例）。另外，每个域也可以是一个服务，可能通过服务层暴露出来。

【讨论】：