Présentation CQRS à DevoxxFr

4 693 vues

Publié le

Présentation CQRS - Commands/Queries Responsibility Segregation - à la conférence DevoxxFR

Publié dans : Technologie
0 commentaire
2 j’aime
Statistiques
Remarques
  • Soyez le premier à commenter

Aucun téléchargement
Vues
Nombre de vues
4 693
Sur SlideShare
0
Issues des intégrations
0
Intégrations
44
Actions
Partages
0
Téléchargements
34
Commentaires
0
J’aime
2
Intégrations 0
Aucune incorporation

Aucune remarque pour cette diapositive

Présentation CQRS à DevoxxFr

  1. 1. CQRSdid you mean CARS ? Jérémie Chassaing @thinkb4coding 1
  2. 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 2
  3. 3. Speaker• http://thinkbeforecoding.com• @thinkb4coding• Architecte chez Siriona• Membre du Advisory Board CQRS au près du groupe Patterns & Practices de Microsoft 3
  4. 4. Commençons parLes bonnes pratiques 4
  5. 5. Architecture 3 tiers 5
  6. 6. Architecture 3 tiers• Chargements à la demande• Prefetch paths ou SELECT 1+N• ORMs• Cache 6
  7. 7. On est en droit de se demander:Est-ce qu’on ne secomplique pas un peu la vie ? 7
  8. 8. CQRS Command/QueryResponsibility Segregation CQS au niveau architectural 8
  9. 9. Vue d’ensembles Evénements 9
  10. 10. Coté requêtes 10
  11. 11. Coté commandes 11
  12. 12. Intégration• Vues SQL• Map reduce sur une base de documents• Projections d’un flux d’evenements• Toute autre solution adéquate ! 12
  13. 13. Vue d’ensembles Evénements 13
  14. 14. A ce niveau là on peut se demander : Est-ce vraiment plus simple ? 14
  15. 15. Deux modèles pour deux besoinsRequetes : Model de vue persistant Commandes : Model transactionnel • Un model par vue • Un modèle par agrégat • Modèles dénormalisés • Respect strict des limites transactionnelles des agrégats • Suit les relations entre objets/contextes • Pas de relations 15
  16. 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 16
  17. 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. 17
  18. 18. Choix du stockage avec CQRSCoté requêtes Coté commandes • SQL (avec ORM/Micro ORM ou sans ORM) • SQL + ORM • Key Value store • Document Store • Document Store • Event Store • Projections en mémoire • Là aussi, écoutez vos besoins et vos contraintes ! • Cube OLAP • Ce qui vous convient ! 18
  19. 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 ! 19
  20. 20. Montée en chargeCoté requêtes : Balance de charge Coté commandes : Sharding 20
  21. 21. Quand utiliser CQRS ? 21
  22. 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 22
  23. 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 23
  24. 24. Conclusion Et oui, déjà… 24
  25. 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 25
  26. 26. Conclusion• Arrêtez de vous compliquer la vie• Utilisez CQRS dès aujourd’hui !• Plus d’info sur github.com/mspnp 26
  27. 27. Questions ? 27

×