1

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

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

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

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

public void CreateUser()
{
    CreateUserInSystemA();
}

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

所以问题是：

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

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

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

4

1 回答 1

1

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

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

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

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

2) 流程变化需要集成行为的变化，而不是子系统的变化。

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

于 2013-04-25T16:35:43.750 回答