如何选择使用域事件还是让应用程序层协调一切

我正在迈入域驱动设计的第一步，购买了蓝皮书和其他所有书籍，我发现自己看到三种实现特定解决方案的方法。作为记录：我没有使用CQRS或事件源。

假设有一个用户请求进入了应用程序服务层。出于某种原因，该请求的业务逻辑分为实体上的方法和域服务上的方法。我应该如何去调用那些方法？

到目前为止，我收集的选项有：

• 让应用程序服务调用这两种方法
• 使用方法注入/双重调度将域服务注入到实体中，让实体来做，然后让它调用域服务的方法（或者反之，让域服务在实体上调用方法）
• 在实体方法中引发一个域事件，该事件的处理程序调用域服务。（我正在谈论的域事件是：http : //www.udidahan.com/2009/06/14/domain-events-salvation/）

我认为这些都是可行的，但我无法在它们之间进行选择。我已经考虑了很长时间了，直到现在我再也看不到这三者之间的语义差异了。您知道什么时候使用什么准则吗？

让应用程序服务调用这两种方法

为此，应用程序服务通常是一个很好的起点，但是您应该始终尝试使行为尽可能地靠近实体。应用程序服务扮演协调角色，它为执行域行为设置了阶段，并因此提供了所有必需的依赖关系。但是，应尽可能将行为委托给域模型。

使用方法注入/双重调度将域服务注入到实体中，让实体来做，然后让它调用域服务的方法（或者反之，让域服务在实体上调用方法）

这是一种更好的方法，因为更多的行为都委派给了实体或域服务。实现此目的最不相关的方法是让实体表达对服务的依赖性，这是提供当前行为的方法的参数。

在实体方法中引发一个域事件，该事件的处理程序调用域服务。

正如Udi和Evans本人所解释的那样，领域事件模式非常灵活，可以应用于各种场景。但是，它伴随着一些复杂性。首先，您必须确保在域事件发布者中具有适当的范围。在大多数情况下，您的域事件处理程序将具有依赖性，如果您使用的是IoC容器，则必须确保注入了正确的实例。例如，在Web应用程序中[ThreadStatic]属性对于范围界定是有问题的。另一个复杂性是转录边界的复杂性。您必须考虑事务，因为如果实体引发域事件，但是随后对数据库的提交失败，则所有域事件处理程序都将需要一种回滚方式，否则最终将引发无效事件。但是，如果您已经涵盖了这些基础，那么域事件是将域逻辑封装在实体本身中的一种很好的模式。

方法2和方法3之间的差异取决于用例。当您要响应事件（过去时）时调用其他行为时，将应用域事件。这是一个重要的约束，因为域事件处理程序不会影响实体的行为。另一方面，在方法2中，注入服务有可能影响行为，因为它被声明为特定行为的依赖项。