Où SignalR appartient-il à une architecture DDD?

Question

J'ai une application DDD et je suis en train de comprendre où SignalR s'inscrit dans mes couches:

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

Fondamentalement, mon hub SignalR avertit les clients (app web angulaire) quand il y a de nouvelles données. Pour lequel je cours un service d'arrière-plan dans un thread d'arrière-plan qui vérifie la base de données sur un intervalle et notifie les clients quand il y a de nouvelles données.

Je suis enclin à penser ainsi:

1. Le moyeu SignalR appartient à la couche Presentation. Étant donné que mon projet de présentation est purement client (Angular), j'ajouterais un nouveau projet sous Présentation juste pour le hub.
2. Le service d'arrière-plan qui vérifie la base de données sur un intervalle semble approprié pour la couche Application. J'injecterais une interface INotify avec une méthode Notify, que j'implémenterais avec SignalR.

Est-ce le long des principes DDD?

Answer 1

DDD est tout à faire en sorte que changements à vos données ne se produisent que d'une manière bien définie, et où le code qui exécute ces changements est défini en termes d'une Ubiquitious Langue qui est bien comprise dans l'ensemble entreprise entière (pas seulement l'équipe de développement).

DDD est muet sur le mécanisme utilisé pour l'interface avec vos utilisateurs et d'autres systèmes, autre que de recommander une architecture en couches - ce que vous semblez faire déjà.

Alors - je ne vous inquiétez trop de DDD ici - mais il est utile d'examiner votre approche architecturale globale - et en termes de modèles architecturaux en couches, qui correspond bien à votre approche est appelée Ports & Adaptateurs ou Oignon architecture. (1 et 2)

Dans cette architecture, l'extérieur de votre système est considéré comme un ensemble d'adaptateurs qui s'adaptent entre une technologie spécifique et votre couche d'application. Dans votre cas, votre couche WebAPI est un exemple d'adaptateur.

Je recommande de créer un nouvel adaptateur SignalR - vous pouvez le considérer au même niveau que l'adaptateur WebAPI (bien que dans les ports et le langage d'adaptateur, il s'agit d'un adaptateur 'output', vous pouvez donc le dessiner en bas à droite de l'oignon).

En termes d'emplacement de votre processus d'arrière-plan - personnellement, je ne considérerais pas cela comme une partie de la couche application, car elle ne guide pas les cas d'utilisation ou les flux de processus dans votre application. Donc, vous pouvez le mettre dans votre adaptateur SignalR, ou créer un nouveau composant dédié pour cela. Cela dit, vous pouvez trouver un autre concept de DDD utile - DomainEvents - ils pourraient supprimer le besoin d'un thread d'arrière-plan. Dans votre adaptateur SignalR, incluez les gestionnaires d'événements qui s'enregistrent pour gérer DomainEvents, et dans ces gestionnaires, propagez les informations sur l'événement via SignalR vers votre couche de présentation côté client - pas besoin d'interroger la base de données! (Attention - en fonction de la mise en œuvre de votre événement de domaine, vous devrez peut-être prendre en compte le risque lié aux événements publicitaires via SignalR avant que l'agrégat ne soit conservé avec succès ... mais c'est un tout autre sujet.