Présentation CQRS à DevoxxFr
-
Upload
jeremie-chassaing -
Category
Technology
-
view
3.553 -
download
0
description
Transcript of Présentation CQRS à DevoxxFr
1
CQRSdid you mean CARS ?
Jérémie Chassaing@thinkb4coding
2
Ce qui vous attend
• Et si on s’était compliqué la vie avec l’archi 3 tiers ?
• Reprenons les questions à la base avec CQRS
• Redécouvrons la simplicité et la clarté
• Démultiplions nos options de choix architecturaux
3
Speaker
• http://thinkbeforecoding.com
• @thinkb4coding
• Architecte chez Siriona
• Membre du Advisory Board CQRS au près du groupe Patterns & Practices de Microsoft
4
Les bonnes pratiques
Commençons par
5
Architecture 3 tiers
Présentation
Objets métiers
Base de données
6
Architecture 3 tiers
• Chargements à la demande
• Prefetch paths ou SELECT 1+N
• ORMs
• Cache
7
Est-ce qu’on ne se complique
pas un peu la vie ?
On est en droit de se demander:
8
CQRSCommand/Query
Responsibility Segregation
CQS au niveau architectural
9
Vue d’ensembles
Présentation
DomaineEcriture seule
Modèle delecture
Requête
s
Com
mandes
Evénements
10
Coté requêtes
Vue Vue
Modèle de vue
persistantModèle de vue
persistant
Requête Réponse
11
Coté commandes
Vue
Service métierDomaine
Commandes
12
Intégration• Vues SQL
• Map reduce sur une base de documents
• Projections d’un flux d’evenements
• Toute autre solution adéquate !
13
Vue d’ensembles
Présentation
DomaineEcriture seule
Modèle delecture
Requête
s
Com
mandes
Evénements
14
Est-ce vraiment plus simple ?
A ce niveau là on peut se demander :
15
Deux modèles pour deux besoins
Requetes : Model de vue persistant
• Un model par vue
• Modèles dénormalisés
• Suit les relations entre objets/contextes
Commandes : Model transactionnel
• Un modèle par agrégat
• Respect strict des limites transactionnelles des agrégats
• Pas de relations
16
Deux modeles pour deux besoins
• Choix indépendants des systèmes de persistance
• Plus de chargements à la demande (lazy loads)
• Donc plus de prefetch path
17
Choix du stockage en 3tiers• SQL, parce que c’est ce que tout le monde utilise.
• Document Store, c’est sympa, mais on peux pas croiser les données.
18
Choix du stockage avec CQRSCoté requêtes
• SQL (avec ORM/Micro ORM ou sans ORM)
• Key Value store
• Document Store
• Projections en mémoire
• Cube OLAP
• Ce qui vous convient !
Coté commandes
• SQL + ORM
• Document Store
• Event Store
• Là aussi, écoutez vos besoins et vos contraintes !
19
Plus de cache• On cache les requêtes qui prennent du temps à calculer
• Mais quand doit on rafraichir le cache ?
• Quand la donnée change !
20
Montée en chargeCoté requêtes : Balance de charge Coté commandes : Sharding
21
Quand utiliser CQRS ?
22
Quand utiliser CQRS
• A l’intérieur d’un contexte délimité
• Dans les environnements fortement concurrents
• Lorsque les modèles de lecture et d’écriture sont différents
• Pour rendre explicite la fraicheur et l’obsolescence des données
23
Quand ne PAS utiliser CQRS
• Au plus haut niveau du système
• Dans les environnements purement CRUD
• Quand les modèles de lecture et d’écriture sont identiques
24
ConclusionEt oui, déjà…
25
Conclusion
• CQRS amène de la clarté en découplant les problématiques
• CQRS permet d’éviter certains problèmes récurrents
• CQRS peut être implémenté dans un contexte isolé
• CQRS propose un choix ouvert d’implémentations
• CQRS peut cohabiter simplement avec les contextes existants
26
Conclusion
• Arrêtez de vous compliquer la vie
• Utilisez CQRS dès aujourd’hui !
• Plus d’info sur github.com/mspnp
27
Questions ?