Partager via

Appliquer des approches CQRS et CQS dans un microservice DDD dans eShopOnContainers

  • Article

Conseil

Ce contenu est un extrait du livre électronique « .NET Microservices Architecture for Containerized .NET Applications », disponible sur .NET Docs ou sous forme de PDF téléchargeable gratuitement et pouvant être lu hors ligne.

Télécharger le PDF

.NET Microservices Architecture for Containerized .NET Applications eBook cover thumbnail.

La conception du microservice de commandes au niveau de l’application de référence eShopOnContainers est basée sur les principes CQRS. Toutefois, elle utilise l’approche la plus simple, qui consiste simplement à séparer les requêtes des commandes et à utiliser la même base de données pour les deux actions.

Le concept essentiel de ces modèles, et le point important ici, est que les requêtes sont idempotentes : quel que soit le nombre de fois où vous interrogez un système, son état ne change pas. En d’autres termes, les requêtes n’ont pas d’effet secondaire.

Par conséquent, vous pourriez utiliser un modèle de données « lectures » différent de la logique transactionnelle « écritures », bien que le microservice de commandes utilise la même base de données. Il s’agit donc d’une approche CQRS simplifiée.

En revanche, les commandes qui déclenchent des transactions et mises à jour de données changent l’état du système. Avec les commandes, vous devez être prudent quand vous abordez le problème de la complexité et les règles métier en constante évolution. C’est là où vous souhaitez appliquer des techniques DDD pour obtenir un système mieux modélisé.

Les modèles DDD présentés dans ce guide ne doivent pas être appliqués de manière universelle. Ils introduisent des contraintes dans votre conception. Ces contraintes présentent des avantages, notamment une meilleure qualité au fil du temps, en particulier dans les commandes et tout code qui modifie l’état du système. Toutefois, ces contraintes augmentent la complexité avec moins d’avantages pour la lecture et l’interrogation des données.

Un modèle de ce type est le modèle Agrégat, que nous examinerons plus en détail dans les sections suivantes. Brièvement, dans le modèle Agrégat, vous traitez un grand nombre d’objets de domaine comme un seul ensemble en raison de leur relation dans le domaine. Il est possible que vous n’obteniez pas toujours des avantages avec ce modèle dans les requêtes, car celui-ci peut augmenter la complexité de la logique de requête. Pour les requêtes en lecture seule, vous n’obtenez pas les avantages de traitement de plusieurs objets comme un seul agrégat, juste la complexité.

Comme le montre la figure 7-2 de la section précédente, ce guide propose d’utiliser des modèles DDD seulement dans la zone transactionnelle/de mises à jour de votre microservice (c’est-à-dire avec un déclenchement par des commandes). Les requêtes peuvent suivre une approche plus simple et doivent être séparées des commandes, suite à une approche CQRS.

Pour implémenter le « côté requêtes », vous pouvez choisir entre plusieurs méthodes, à partir de votre ORM complet comme EF Core, des projections AutoMapper, des procédures stockées, des vues, des vues matérialisées ou un micro-ORM.

Dans ce guide et dans eShopOnContainers (en particulier le microservice de commandes), nous avons choisi d’implémenter des requêtes simples à l’aide d’un micro-ORM comme Dapper. Ce guide vous permet d’implémenter toute requête basée sur des instructions SQL pour obtenir des performances optimales, grâce à un framework léger avec peu de surcharge.

Quand vous utilisez cette approche, toutes les mises à jour apportées à votre modèle qui affectent le mode de persistance des entités dans une base de données SQL nécessitent également des mises à jour distinctes pour les requêtes SQL utilisées par Dapper ou toutes les autres approches (non-EF) distinctes pour l’interrogation.

Les modèles CQRS et DDD ne sont pas des architectures de niveau supérieur

Il est important de comprendre que CQRS et la plupart des modèles DDD (comme les couches DDD ou un modèle de domaine avec des agrégats) ne sont pas des styles d’architecture, mais seulement des modèles d’architecture. Les microservices, SOA et l’architecture pilotée par événements (EDA) sont des exemples de styles architecturaux. Ils décrivent un système de nombreux composants, tels que de nombreux microservices. Les modèles CQRS et DDD décrivent un élément à l’intérieur d’un système ou composant unique, dans ce cas un élément à l’intérieur d’un microservice.

Des contextes délimités différents vont utiliser différents modèles. Ils ont des responsabilités diverses, ce qui aboutit à différentes solutions. Il est important de souligner que le fait d’imposer le même modèle partout entraîne un échec. N’utilisez pas les modèles CQRS et DDD partout. De nombreux sous-systèmes, contextes délimités ou microservices sont plus simples et peuvent être implémentés plus facilement à l’aide de services CRUD de base ou d’une autre approche.

Il n’existe qu’une seule architecture des applications : l’architecture de l’application système ou de bout en bout que vous concevez (par exemple, l’architecture de microservices). Toutefois, la conception de chaque contexte délimité ou microservice au sein de cette application reflète ses propres compromis et décisions de conception interne à un niveau de modèles d’architecture. N’essayez pas d’appliquer les mêmes modèles d’architecture que CQRS ou DDD partout.

Ressources supplémentaires

PrécédentSuivant