signalr - SignalR 在 DDD 架构中属于哪里？

Question

我有一个 DDD 应用程序，我试图了解 SignalR 在我的层中的位置:

1. Presentation (Angular)
2. Distributed Services (Web API)
3. Application
4. Domain
5. Data

基本上，当有新数据时，我的 SignalR 集线器会通知客户端(Angular Web 应用程序)。为此，我在后台线程中运行后台服务，该线程定期检查数据库并在有新数据时通知客户端。

我倾向于这样想:

SignalR 集线器属于 Presentation层。鉴于我的演示项目是纯粹的客户端(Angular)，我将在演示下添加一个新项目，仅用于集线器。

每隔一段时间检查数据库的后台服务似乎适用于 Application层。我会注入(inject) INotify与 Notify 的接口(interface)方法，我将使用 SignalR 实现。

这符合 DDD 原则吗？

Answer 1

DDD 就是要确保对数据的更改仅以明确定义的方式发生，并且执行这些更改的代码是根据在整个业务中(不仅仅是开发团队)都易于理解的通用语言定义的)。

DDD 对用于与用户和其他系统交互的机制保持沉默，除了推荐分层架构——听起来你已经在这样做了。

所以 - 我不会在这里过多担心 DDD - 但值得考虑您的整体架构方法 - 就分层架构模式而言，与您的方法非常匹配的一种称为端口和适配器或洋葱架构。 (见 1 和 2 )

在此架构中，系统外部被视为一组适配器，可在特定技术和应用程序层之间进行适配。在您的情况下，您的 WebAPI 层是适配器的一个示例。

我建议创建一个新的 SignalR 适配器 - 您可以将其视为与 WebAPI 适配器相同的“级别”(尽管在端口和适配器的说法中它是一个“输出”适配器，因此您可以在洋葱的右下角绘制它) .

就您的后台进程的位置而言 - 我个人不会认为这是应用程序层的一部分，因为它不会指导您的应用程序中的任何用例或流程流。所以，你可以把它放在你的 SignalR 适配器中，或者为它创建一个新的专用组件。

也就是说，您可能会发现 DDD 中的另一个有用的概念 - DomainEvents - 他们可以完全消除对后台线程的需求。在您的 SignalR 适配器中，包括注册以处理 DomainEvents 的事件处理程序，并在这些处理程序中，通过 SignalR 将有关事件的信息传播到您的客户端表示层 - 根本不需要轮询数据库! (警告 - 根据您的域事件实现，您可能需要在聚合成功保存之前考虑通过 SignalR 发布事件的风险......但这是一个完整的“另一个主题。)