Articles

GET sert souvent les vues de lecture, tandis que les écritures demandent une décision métier. REST et CQRS se combinent sans imposer le même découpage.

Un agent peut écrire à partir d’une ancienne version. Une précondition vérifiée par le serveur permet de détecter le conflit et de reprendre sur un état relu.

Une commande expédiée met à jour une liste et déclenche un courriel. Ces effets ne se réparent pas de la même façon : voici comment organiser leur reprise.

Dans un monolithe, un traitement différé peut laisser deux modules en décalage. Quand faut-il attendre une réponse et comment gérer une mise à jour tardive ?

CQRS sépare les modèles de commande et de lecture. L’event sourcing conserve les événements comme référence : deux choix, avec leurs avantages et coûts.

Réserver un vol puis un hôtel peut échouer à mi-parcours. Une saga organise les étapes, leur reprise et les compensations pour terminer le traitement.

Une commande validée peut manquer quelques instants dans une liste, même dans un monolithe. Voici d’où vient ce délai et comment le rendre compréhensible.

Une liste de commandes, une recherche et un tableau de bord ont des besoins différents. Le read model prépare ces vues et permet de gérer leur mise à jour.

Deux clients achètent le dernier billet : comment éviter la double vente et envoyer la confirmation ? Transaction, concurrence et outbox expliquées pas à pas.

Avec CQRS, réserver une chambre et afficher les disponibilités reposent sur deux modèles adaptés à ces besoins. Deux bases de données ne sont pas obligatoires.

Une donnée absente ou ancienne ne bloque pas tous les usages. Choisir, opération par opération, quand attendre, limiter le service ou accepter un retard.

CQRS distingue les règles qui valident une opération des données préparées pour les vues. Une commande client explique les deux modèles et leur synchronisation.