Migrer vers le Event Sourcing, partie 7: construire un modèle de lecture

An english version of this post is available here.

Vue d’ensemble

Dans cette étape, nous nous concentrons sur la partie “requêtage” de CQRS. Nous allons pouvoir utiliser des vues conçues pour des pages spécifiques de l’application.

Avantages

Simplicité

Les tables SQL des vues sont uniquement responsables de l’affichage. Vous pouvez dé-normaliser autant que vous voulez. Vous n’êtes plus contrains par l’aspect transactionnel de votre application. Vous n’avez qu’à vous soucier de l’affichage et de la recherche. Cela signifie que ces tables sont plus simples, qu’elles contiennent moins de clefs étrangères, et qu’elle sont plus isolées (moins de dépendances). Le code source et le schéma de données résultants seront moins complexe, et donc plus maintenable. Cela accélérera probablement votre équipe lorsque vous ajouterez des fonctionnalités à votre application.

Performance

Habituellement, cette étape se débarrasse de la plupart des problèmes de performance dont votre application soufrait avec une simple modèle de données partagé. Avec une application classique, votre modèle de données transactionnel résultait habituellement en un modèle “toile d’araignée”, très intriqué. Cela signifie en général que pour afficher certaines pages, vous avez besoin de grosse requêtes inefficaces, comprenant beaucoup de jointures et autres opérations coûteuses pour la performance. Avec un modèle d’affichage conçu spécifiquement pour une page données, ces problèmes disparaissent. Vous pouvez par exemple pré calculer vos rapports en temps réel (est ce que cela a une valeur d’affaire pour votre compagnie?).

Implémentation

Ce qui a changé

Rien! Ce qui est sympathique, c’est que nous avons déjà un modèle d’affichage: l’ancien modèle transactionnel qui nous persistons avec les gestionnaires d’événements. Nos DTOs sont déjà récupérés à partir de ces tables. Alors bien sûr, ce n’est pas le modèle d’affichage le plus optimisé, mais c’est un bon point de départ. Pour l’instant, nous ne pouvons toujours pas le modifier, car nous utilisons toujours les tables pour charger nos entités. Cette limitation sautera lors de la prochaine étape, et en attendant, rien ne nous empêche de créer d’autres tables spécifiques à nos vues. En fait, nous pouvions le faire depuis que nous persistons les entités via nos gestionnaires d’événements.

Démarrer l’application exemple

Les sources pour toute la série de billets sont disponible sur GitHub à http://github.com/jletroui/TransitioningToEventSourcing
.

Vous aurez simplement besoin de créer une base de données vide intitulée “DDDPart6″ dans SQLExpress avant de lancer l’application.
Les 3 dernières étapes de cette série étant très simples, l’exemple “partie 6″ couvre en fait les parties 6 à 8.

Liste des billets “migrer vers le Event Sourcing”:

• Partie 1: L’application DDD “légère”.
• Partie 2: Etre CQRS en utilisant des DTOs pour les requêtes.
• Partie 3: Définir les commandes de façon explicite.
• Partie 4: Garder trace des changements.
• Partie 5: Utiliser les événements pour mettre à jour la base de données.
• Partie 6: Stocker les événements.
• Partie 7: Utiliser les événements pour construire un modèle de lecture.
• Partie 8: Supprimer la base relationnelle, devenir “Event Sourced”.
• Partie 9: Passer rapidement sur les points avancés: versionement, stratégies de fusion intelligentes, consistance décalée, montée en charge coté requête, montée en charge coté transactionnel.