Dans les systèmes basés sur des commandes et/ou des événements (CQRS, CQS, UpdateUserStatus ou UserStatusUpdated. Ces classes sont généralement une mauvaise abstraction. Il vaut mieux privilégier CloseUserAccount ou UserAccountClosed. Pourquoi ? Parce qu’une sémantique explicite améliore la compréhension du système. Avec des Dans un système event-sourced, des événements spécifiques ont l'avantage de // À éviter handle(cmd: UpdateUserStatus) { if (cmd.status === "Closed") { closeAccount(cmd); } else { throw new Error( "Unsupported update. [Status=" + cmd.status + "]" ); } } // Préférable handle(cmd: CloseUserAccount) { // … } Le contre-argument le plus fréquent est que cette approche multiplie le nombre Une classe supplémentaire n’aura aucun impact significatif sur les performances Mon dernier point concerne la documentation du système. Cartographier les messages (qui produit ou consomme quoi) est déjà complexe. Si, en plus, il faut analyser le contenu de chaque message, ça devient presque impossible.