cqrs

Xendor

Xendor est un framework Core .NET qui peut être utilisé pour créer une conception simple et propre en appliquant une responsabilité unique et une séparation des préoccupations. Ses fonctionnalités avancées sont idéales pour la conception pilotée par le domaine (DDD), la ségragation de la responsabilité de la requête de commande (CQRS) et l'approvisionnement en événement. Xendor a également des intégrations RabbitMQ.

Qu'est-ce que CQRS?

La ségrégation de la responsabilité de la quête de commande est un modèle qui nous indique de séparer les opérations qui mutent les données de celles qui les interrogent. Il est dérivé de CQS de séparation des requêtes de commande (CQS) indique qu'il ne peut y avoir que deux types de méthodes sur une classe: celles qui mutent l'état et le retour vide et celles qui retournent l'état mais ne le changent pas.

CQRS est un modèle sur lequel vous vous appliquez? L'avoir? de votre service / application et vous pouvez l'appliquer uniquement à la partie de votre service.

Ce n'est pas CQRS

Ce n'est pas une cohérence éventuelle

Ce n'est pas conteste

Ce n'est pas la messagerie

Il n'a pas de modèles séparés pour la lecture et l'écriture

Il n'utilise pas non plus l'approvisionnement en événements.

CQRS PROS & CONS

Avantages:

• Meilleures performances et évolutivité de votre système.
• Mieux manutention d'accès simultanée.
• meilleure évolutivité de l'équipe.
• Modèle de domaine moins complexe et modèle de requête simple.

Inconvénients:

• Les modèles de lecture et d'écriture doivent être conservés en synchronisation.
• Coûts de maintenance et d'administration Si vous choisissez deux moteurs différents pour la lecture et pour l'écriture.
• La cohérence éventuelle n'est pas toujours autorisée.

Qu'est-ce que l'approvisionnement des événements?

Au lieu de stocker uniquement l'état actuel des données dans un domaine, utilisez une boutique annexe pour enregistrer la série complète d'actions prises sur ces données. Le magasin agit comme le système d'enregistrement et peut être utilisé pour matérialiser les objets de domaine. Cela peut simplifier les tâches dans des domaines complexes, en évitant la nécessité de synchroniser le modèle de données et le domaine commercial, tout en améliorant les performances, l'évolutivité et la réactivité. Il peut également fournir une cohérence pour les données transactionnelles et maintenir les sentiers d'audit complètes et l'historique qui peuvent permettre des actions de rémunération.

Dans quels systèmes vaut-il la peine d'utiliser l'approvisionnement en événements?

• Votre système a de nombreux comportements qui ne sont pas un crud ordinaire.
• Le recréer des états historiques d'objets est très important
• Les utilisateurs professionnels voient les avantages d'avoir l'historique complet pour les statistiques, l'apprentissage automatique ou à d'autres fins.
• Votre domaine est mieux décrit par les événements (par exemple, une application pour suivre les activités d'un véhicule d'assistance).

Avantages et inconvénients de l'approvisionnement des événements

Avantages:

• Ajouter le modèle uniquement est idéal pour les performances, l'évolutivité
• Pas de blocages
• Les événements (faits) sont bien compris par l'expert commercial, certains domaines sont intrinsèquement d'origine d'événements: comptabilité, soins de santé, trading
• Trace d'audit gratuitement
• Nous pouvons obtenir un état d'objet à tout moment dans le temps
• facile à tester et à déboguer
• modèle de données découplé du modèle de domaine
• Aucune non-concordance d'impédance (modèle d'objet vs modèle de données)
• flexibilité? De nombreux modèles de domaine différents peuvent être construits à partir du même flux d'événements
• Nous pouvons utiliser ce modèle avec des événements d'inversion, des événements rétroactifs
• Plus d'orms? Grâce au fait que notre objet est construit à partir d'événements, nous n'avons pas à le refléter dans une base de données relationnelle

Inconvénients:

• Pas de moyen naturel pour les développeurs de gérer les agrégats d'État et de construire des agrégats, prend du temps pour s'y habituer
• Interroger au-delà d'un agrégat est un peu plus difficile (vous devez construire des projections pour chaque type de requête que vous souhaitez ajouter au système),
• Les changements de schéma d'événements sont beaucoup plus difficiles que dans le cas d'un modèle relationnel (manque d'outils de migration de schéma standard)
• Vous devez envisager la manipulation du versioning depuis le début.

Source des événements - Projections

La projection est un concept important lors de la construction de systèmes centrés sur les événements. En même temps, c'est extrêmement simple.

La projection consiste à dériver l'état actuel du flux d'événements.

Par exemple, considérez une situation, où un flux d'événements est publié par un serveur à tous les abonnés. Ces événements sont liés aux inscriptions des utilisateurs et ressemblent à:

UserAddedToAccount

{
 "userId" : 55 ,
 "username" : " alemol " ,
 "name" : " Alejandro " ,
 "lastName" : " Moline "
}

UserVerifiedEmail

{
 "userId" : 55 ,
 "email" : " [email protected] "
}

Userupdated

{
 "userId" : 55 ,
 "lastName" : " Molines "
}

Nous pouvons joindre un abonné au flux de ces événements pour projeter ce flux dans un modèle de lecture persistant, utilisé pour servir les détails des utilisateurs dans une interface utilisateur Web. Le modèle de lecture finale pourrait ressembler:

{
 "userId" : 55 ,
 "username" : " alemol " ,
 "email" : " [email protected] " ,
 "name" : " Alejandro " ,
 "lastName" : " Molines "
}

CQRS avec source d'événements (CQRS-ES)

Donnez une étoile!

Si vous aimez ou utilisez ce projet, veuillez lui donner une étoile. Merci!

J'ai trouvé un problème ou j'ai une demande de changement

N'hésitez pas à créer un problème sur GitHub. Les contributions, les demandes de traction sont plus que les bienvenues!

Xendor est Copyright © 2019 Alejandro Molines et autres contributeurs sous la licence du MIT.