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 ?