CQRS et Event Sourcing en PHP : Architecture pour projets complexes

Pourquoi le CRUD classique cesse de fonctionner quand le projet grandit

Imaginez : vous développez une boutique en ligne en PHP. Au début, tout est simple — ajouter un produit, modifier un prix, supprimer. Mais six mois passent, et de nouvelles exigences apparaissent : audit de toutes les modifications, restauration des données à une date donnée, logique complexe de remises. Le CRUD classique (Create, Read, Update, Delete) commence à montrer ses limites. La base de données devient un fouillis, et chaque nouvelle demande client nécessite de réécrire la moitié du système.

Ça vous parle ? Alors CQRS (Command Query Responsibility Segregation) et Event Sourcing vous seront certainement utiles — deux patrons puissants qui changent l'approche du développement. Dans cet article, nous les analyserons avec des exemples concrets en PHP, afin que vous puissiez les appliquer dans vos projets.

Qu'est-ce que CQRS et Event Sourcing en termes simples

CQRS : séparation des commandes et des requêtes

CQRS est un patron architectural qui sépare les opérations en deux types : les commandes (modifient l'état) et les requêtes (lisent l'état). Dans le MVC classique, le contrôleur et le modèle travaillent avec les mêmes entités. CQRS propose de séparer ces responsabilités.

Imaginez une bibliothèque : il y a un bureau dédié pour l'enregistrement des livres (commandes) et un autre pour la lecture (requêtes). Personne ne se gêne, et chacun est optimisé pour sa tâche.

Event Sourcing : l'historique des modifications plutôt que l'état actuel

Event Sourcing est une méthode de stockage de données où vous ne sauvegardez pas l'état actuel d'un objet, mais la séquence de tous les événements qui y ont conduit. Au lieu d'une seule ligne "Commande n°123 : statut = livré", vous stockez : "Commande créée → Payée → Expédiée → Livrée".

C'est comme un enregistrement vidéo plutôt qu'une photo : vous pouvez toujours revenir en arrière et voir ce qui s'est passé à tout moment.

Quand utiliser CQRS et Event Sourcing en PHP

Ces patrons ne sont pas une solution miracle. Pour un simple blog, ils sont superflus. Mais voici les scénarios où ils sont indispensables :

\n
• Logique métier complexe (finance, réservation, logistique)
\n
• Exigences d'audit — besoin de savoir qui et quand a modifié les données
\n
• Restauration d'état à n'importe quelle date
\n
• Architecture microservices — les événements se transmettent facilement entre les services
\n
• Forte charge en lecture — possibilité de créer un modèle de lecture séparé, optimisé pour les requêtes
\n

Si votre projet est une boutique en ligne avec des milliers de commandes, un système CRM ou une application bancaire — CQRS et Event Sourcing vous seront certainement utiles.

Implémentation pratique de CQRS en PHP

Passons au code. Nous allons implémenter un système simple de gestion de commandes. Commençons par CQRS.

Étape 1 : Définir les commandes et les requêtes

Une commande est un DTO (Data Transfer Object) qui contient toutes les données nécessaires à l'exécution d'une opération. La commande ne retourne jamais de données — elle modifie uniquement l'état.

<?php\n// src/Application/Command/CreateOrderCommand.php\nnamespace App\\Application\\Command;\n\nclass CreateOrderCommand\n{\n    public function __construct(\n        public readonly string $orderId,\n        public readonly string $customerId,\n        public readonly array $items, // [['productId' => '...', 'quantity' => 2], ...]\n        public readonly \\DateTimeImmutable $createdAt\n    ) {}\n}\n

Une requête est aussi un DTO, mais pour la lecture. Elle peut contenir des filtres et retourner des données.

<?php\n// src/Application/Query/GetOrderQuery.php\nnamespace App\\Application\\Query;\n\nclass GetOrderQuery\n{\n    public function __construct(\n        public readonly string $orderId\n    ) {}\n}\n

Étape 2 : Créer les gestionnaires de commandes

Un gestionnaire de commande est un service qui exécute la logique métier. Il reçoit une commande et modifie l'état.