tadata
Retour à l'accueil

CQRS & Event Sourcing : quand la complexité se justifie

#architecture#cqrs#event-sourcing#distributed-systems

Command Query Responsibility Segregation (CQRS) et Event Sourcing sont souvent mentionnés ensemble mais sont des patterns indépendants. Comprendre quand chacun apporte de la valeur -- et quand le surcoût n'est pas justifié -- est la décision architecturale clé.

CRUD Traditionnel vs CQRS

DimensionCRUD TraditionnelCQRS
Modèle de donnéesModèle unique lectures/écrituresModèles séparés lecture et écriture
ScalabilitéTout évolue ensembleLectures et écritures scalent indépendamment
CohérenceForte (même BDD)Éventuelle (latence de projection)
ComplexitéFaibleÉlevée (deux modèles, synchronisation)
Flexibilité requêtesLimitée par le schéma d'écritureModèles de lecture optimisés par usage
Piste d'auditNécessite du logging supplémentaireNative avec event sourcing
Coût stockageInférieurSupérieur (événements + projections)

Matrice de décision

CritèreScore 0 (éviter)Score 1 (envisager)Score 2 (bon candidat)
Exigences d'auditAucun auditJournal d'audit requisRequêtes temporelles complètes
Ratio lecture/écritureÉquilibre10:1 lectures100:1+ lectures
Complexité métierCRUD simpleWorkflows modérésMachines à états complexes
Taille équipe< 3 développeurs3-8 développeurs8+ développeurs
Diversité des requêtes1-2 patterns3-5 patterns6+ patterns
RéglementaireAucunLignage nécessaireRejouabilité complète requise

Interprétation : 0-3 total = rester en CRUD, 4-7 = envisager CQRS sans event sourcing, 8-12 = CQRS + event sourcing justifié.

Compromis complexité / bénéfice

PatternCoût d'implémentationCoût opérationnelDebuggingIdéal pour
CRUD SimpleFaibleFaibleFacileGestion de contenu, paramètres
CQRS (sans ES)MoyenMoyenModéréAPIs haute lecture, dashboards
ES (sans CQRS)Moyen-ÉlevéMoyenDifficileDomaines riches en audit
CQRS + ESÉlevéÉlevéTrès difficileFinance, réglementé, temporel

Décisions d'infrastructure clés

Options d'Event Store : EventStoreDB (dédié), Apache Kafka (si déjà en place), PostgreSQL avec tables append-only (début simple), AWS DynamoDB Streams.

Stratégie de reconstruction des projections : Vous devrez reconstruire les projections. Concevez pour cela dès le premier jour. Suivez la version des projections, supportez les reconstructions parallèles.

Snapshotting : Pour les agrégats avec de longs historiques d'événements (1000+), des snapshots périodiques évitent le chargement lent.

Ressources

Nous utilisons des cookies analytiques pour améliorer votre expérience. Aucune donnée personnelle n'est collectée.