J'essaie de mettre en œuvre le service DDD avec l'utilisation de l'approche CQRS. Je n'utilise pas l'approvisionnement des événements. J'ai donc 3 couches: application, infrastructure et domaine. De nombreux peuples ont déclaré que vous pouvez contourner le domaine des requêtes et ça va. Par exemple, imaginez que cela me soit nécessaire à cause des problèmes de performance.
Après l'ignorance de la persistance, j'ai une mise en œuvre du référentiel dans l'infrastructure. Comme je le vois dans toutes les implémentations de DDD et de livres, les infrastructures ne doivent pas dépendre de la couche d'application.
Alors, ce que j'ai besoin de revenir du référentiel ?? Si DTO (Lisez des modèles, affichez des modèles, cela n'a pas d'importance) est une préoccupation d'application. Les placer sur la couche d'infrastructure rend une dépendance circulaire de l'application à l'infrastructure et inversement. Mais la mise en œuvre de la logique de requête (si j'utilise ORM qui pose des questions en écrivant SQL brut) est une mauvaise approche car, à cette fin, nous avons créé le référentiel dans l'infrastructure (c'était la voie de https://github.com/dotnet-architecture/eshoponcontainers ).
Une autre approche est la charge des agrégats de charge du référentiel, puis de les convertir en DTO, mais il est impossible en raison de mes problèmes de fiction. Alors, comment gérer cela de bonne manière? (C'était la voie de https://github.com/jasongt/northwindtraders/ )
3 Réponses :
Si vous souhaitez suivre une architecture propre de Robert C. Martin, vous devez séparer des règles métiers stables (abstractions de niveau supérieur) des détails techniques volatils (détails de niveau inférieur), définissant des frontières claires. Vos dépendances de code source ne doivent pointer que vers l'intérieur, vers des politiques de niveau supérieur. Pour y parvenir, utilisez le principe d'inversion de dépendance. Définissez des interfaces pour les référentiels en couche où vous en avez besoin. Ensuite, mettez en œuvre ces référentiels dans la couche d'infrastructure.
Cela signifie que la couche d'application ne doit pas dépendre de la couche d'infrastructure. Mais la couche d'infrastructure peut dépendre de la couche d'application (l'infrastructure peut utiliser l'application).
D'accord, mais dans chaque source \ Article \ Book Dto - est une préoccupation de l'application, de sorte que nous les plaçons. Et puis si vous souhaitez retourner directement DTO - il s'agit d'une dépendance de la mise en œuvre et du domaine (car l'interface est là). Comment faire face à cela.
Un modèle de lecture idéalisé semble beaucoup comme un cache - vous obtenez une requête, vous utilisez la requête pour calculer une clé de cache, vous renvoyez les octets stockés à l'aide de cette clé de cache.
Que se passe-t-il sur une cache Miss? Ensuite, vous devez rechercher les données et calculer ce que les octets sont retournés devraient être.
Alors, ce que vous essayez d'obtenir est de récupérer l'état dont vous avez besoin de votre magasin durable, puis de la convertir à cet état dans la représentation sérialisée que l'appelant comprendra, sans faille inutile.
Par exemple, imaginez une API Web, où le client vous transmet une URI cible et attend une réponse d'application Si vous êtes plus à l'aise avec O / RM, vous pourriez définir une représentation de l'objet de mémoire, et laissez l'O / RM s'inquiéter de la création d'une représentation en mémoire du résultat, que vous passez ensuite à la bibliothèque de désériorialisation JSON.
Le point ici est que ce composant de traduction doit comprendre comment interpréter la valeur extraite du magasin durable et comment exprimer cette valeur dans une représentation qui sera comprise par le client - mais vous n'avez pas t besoin entités . Vous êtes "juste" prendre des messages et les transformer en autres messages.
Selon quelles parties de la traduction sont stables et qui doivent être substituables, vous pourriez avoir un certain nombre de conceptions utiles ici. Mais la mise en œuvre de votre traduction n'a pas besoin d'avoir aucune dépendance sur les détails de la mise en œuvre de votre modèle d'écriture. JSON . Votre Store de données standard est de SMDBMS, vous utilisez donc votre client SQL de tablette pour exécuter une requête, ce qui produit un résultatsset . Vous utiliseriez ensuite quelque chose comme un constructeur DOM pour construire un arbre, itérant sur les lignes dans le résultat et copier les colonnes de données dans l'arborescence. Lorsque l'arborescence est terminée, vous utiliseriez votre bibliothèque JSON pour une représentation extra-une représentation UTF-8 de l'arborescence. Tada, vous avez une représentation de la réponse que vous pouvez coller dans le cache et revenir au client.
Je ne comprends pas complètement l'idée, pourriez-vous fournir un morceau de code ou un peu de repo git? Si je comprends bien, vous parlez de la liaison dynamique des données directement à partir d'une sorte d'ormes?
Comme je le vois dans toutes les implémentations de DDD et de livres, Infrastructure ne devrait pas dépendre de la couche d'application.
Ce n'est pas la vérité du tout. L'infrastructure dépend de la couche d'application. Regardez la figure 4.3 (page 124) du livre rouge de Vaughn Vernon IDDD.
Par exemple, les services transversaux (authentification et autorisation, transactionnelle, etc.) sont définis lors de la couche d'application et la mise en œuvre est à l'infrastructure.
Alors, ce que j'ai besoin de revenir du référentiel ?? Si DTO (Lire les modèles, Voir les modèles, cela n'a pas d'importance) est une préoccupation d'application. Les placer sur la couche d'infrastructure fait une dépendance circulaire de l'application à l'infrastructure et inversement. Mais mettre en œuvre logique de requête (si j'utilise orm qui pose des questions en écrivant SQL cru) est un mauvais approche parce que, à cet effet, nous avons créé le référentiel dans Infrastructure
Si vous utilisez des CQRS, vous avez un modèle différent pour les requêtes. Les référentiels font partie du modèle de commande. Dans le modèle Q, vous définissez la requête dont vous avez besoin dans la couche d'application, renvoyant des objets nécessaires par le client (par exemple une vue). La mise en œuvre de la requête est dans la couche d'infrassetructure, à l'aide de SQL directement.