我有一个DDD应用程序，我正在尝试了解SignalR在我的图层中的位置：
1. Presentation (Angular)
2. Distributed Services (Web API)
3. Application
4. Domain
5. Data
基本上，我的SignalR中心会在有新数据时通知客户端（Angular Web app）。为此，我在后台线程中运行后台服务，该后台线程在一个时间间隔内检查数据库，并在有新数据时通知客户端。
我倾向于以这种方式思考：
Presentation层。鉴于我的演示项目纯粹是客户端（Angular），我会在Presentation下添加一个新项目，仅用于集线器。Application层。我会使用INotify方法注入Notify接口，我将使用SignalR实现该方法。这是否符合DDD原则？
答案 0 :(得分：3)
DDD完全是为了确保更改只能以明确定义的方式发生数据，并且执行这些更改的代码是根据 Ubiquitious Language 在整个业务中都很容易理解（不仅仅是开发团队）。
DDD对用于与用户和其他系统进行交互的机制保持沉默，而不是推荐分层架构 - 这听起来像你已经在做的那样。
所以 - 我不会在这里担心DDD太多 - 但是值得考虑你的整体架构方法 - 并且在分层架构模式方面，与你的方法匹配良好的方法称为 Ports＆amp; ;适配器或洋葱架构。 （请参阅1和2）
在此体系结构中，系统外部被视为一组适配器，可在特定技术和应用程序层之间进行调整。在您的情况下，您的WebAPI层是适配器的示例。
我建议您创建一个新的SignalR适配器 - 您可以将它视为同一级别＆＃39;作为WebAPI适配器（虽然在端口和适配器用语中它是一个＆＃39;输出＆＃39;适配器，所以你可以在洋葱的右下角绘制它。）
就后台进程的位置而言 - 我个人认为这不是应用程序层的一部分，因为它不会指导应用程序中的任何用例或进程流。因此，您可以将它放在SignalR适配器中，或者为它创建一个新的专用组件。
也就是说，您可能会发现DDD的另一个概念很有用 - DomainEvents - 它们可以完全消除对后台线程的需求。在SignalR适配器中，包括注册以处理DomainEvents的事件处理程序，在这些处理程序中，通过SignalR将有关事件的信息传播到客户端表示层 - 根本不需要轮询数据库！ （警告 - 根据您的域事件实施情况，您可能需要考虑在成功保留聚合之前通过SignalR广告事件的风险......但这是一个完整的主题。）