Question

以DDD方式将EventDispatcher注入实体是否正确？

想象一下，我有一个名为Card的DomainModel。可以激活和停用无处不在的语言中的该卡。但激活和停用涉及调用它在现实世界中激活的第三方API。

为了保持我们的域模型清晰，我的方法是我的卡实体有一个看起来像这样的激活方法：

public function activate()
{
    $this->active = true;

    $this->dispatcher->dispatch(CardEvents::CARD_ACTIVATION, new CardActivation($this));
}

然后，服务正在侦听调度程序以使用外部API激活或不激活。

将EventDispatcher注入实体是否正确？

如果对api的调用失败，该方法是什么？

听说服务最终会改变卡本身的活动属性吗？

感谢。

Answer 1

如果activate方法中的这个EventDispatcher只是对域中接口的引用，那么是的，没关系。然后，您将此接口从您的域公开到另一个层，并创建一个实现所述接口的类（例如在应用程序层中），并且可以使用第三方库或其他任何内容来实现此类。这样，您的域名就不知道IEventDispatcher接口是如何实现的，从而保证其免受更改。

请记住，更改此EventDispatcher的实现方式（如果它使用第三方插件，或者您自己实现）不应影响您的域/业务逻辑。也许消耗它的应用程序可能会受到影响。您可能有许多应用程序（Web，移动设备，桌面）可能会使卡无效，每个应用程序具有不同的EventDispatcher版本/实现（或相同），这不会影响您的域。如果是，那么你应该检查你的设计。

此外，只有在必须调用它时，我才会将EventDispatcher保留在您的Card模型中，无论应用程序（Web，桌面，移动设备，Web服务）请求activate()方法，这意味着调用{{ 1}} 某些EventDispatcher 的方法是业务逻辑的一部分（注意强调某些字，因为域名不知道如何实现， it），只是因为你的域名希望为应用程序提供一个 dispatch 的机会，无论它是否有效，如果它做了某些事情（域名不关心它，它只是称之为。）

以DDD方式将EventDispatcher注入实体

1 个答案: