Where does SignalR belong in a DDD architecture?

Question

I have a DDD application and I am trying to understand where SignalR fits in my layers:

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

Basically, my SignalR hub notifies clients (Angular web app) when there is new data. For which I run a background service in a background thread that checks the database on an interval and notifies clients when there is new data.

I am inclined to think in this way:

1. The SignalR hub belongs to the Presentation layer. Given that my presentation project is purely client-side (Angular), I would add a new project under Presentation just for the hub.
2. The background service that checks the database on an interval seems appropriate for the Application layer. I would inject an INotify interface with a Notify method, which I would implement with SignalR.

Is this along the DDD principles?

Answer 1

DDD is all about ensuring that changes to your data only happen in a well-defined way, and where the code that executes those changes is defined in terms from a Ubiquitious Language which is well-understood throughout the whole business (not just the dev team).

DDD is silent on the mechanism used to interface with your users and other systems, other than recommending a layered architecture - which it sounds like you're already doing.

So - I wouldn't worry too much about DDD here - but it is worth considering your overall architectural approach - and in terms of layered architectural patterns, one that matches well to your approach is called Ports & Adaptors or Onion architecture. (see 1 and 2)

In this architecture, the outside of your system is considered as a set of adaptors that adapt between specific technology and your application layer. In your case your WebAPI layer is an example of an adaptor.

I would recommend creating a new SignalR adaptor - you can consider it at the same 'level' as the WebAPI adaptor (although in ports and adaptor parlance it's an 'output' adaptor, so you might diagram it on the bottom right of the onion).

In terms of the location of your background process - personally I would not consider that a part of the application layer, as it does not guide any use cases or process flows in your application. So, you could put it in your SignalR adaptor, or create a new dedicated component for it.

That said, you may find another concept from DDD useful - DomainEvents - they could remove the need for the background thread altogether. In your SignalR adaptor, include event handlers that register to handle DomainEvents, and in those handlers, propagate the information about the event via SignalR to your client side presentation layer - no need to poll the database at all! (Warning - depending on your domain event implementation, you may need to consider the risk of advertising events via SignalR before the aggregate is successfully persisted... but that's a whole 'nother topic.)