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

Question

使用域事件是DDD应用程序的广泛认可实践，但有些情况对我来说很难。

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

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

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

public void CreateUser()
{
    CreateUserInSystemA();
}

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

所以问题是：

1）这种方法不能有效地隐藏域逻辑吗？通过查看CreateUser方法来查看我们真正在做的事情并不容易。

2）如果（如我们的情况那样），您将需要在系统A和B中创建用户的新工作流程 - 因此不应调用CreateUserInSystemC？如果我们使用现有的CreateUserInSystemB实施，则会引发域事件，并且硬连线CreateUserInSystemC将会运行。

以正确的DDD方式处理此方案的最佳方法是什么？我们是否应该使用Application Service层并为两个工作流公开两个单独的方法，而不是基于Domain Events的流程？

Answer 1

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

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

所以，你的问题的答案将是：

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

2）流量变化需要改变集成行为，而不是子系统。

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