Dans les systèmes basés sur des commandes et/ou des événements (CQRS, CQS,
Event Sourcing, architecture event-driven), on retrouve parfois des messages
“CRUD-like” tels que UpdateUserStatus ou UserStatusUpdated.

Ces classes sont généralement une mauvaise abstraction. Il vaut mieux privilégier
des messages explicites comme CloseUserAccount ou UserAccountClosed.

Pourquoi ?

Parce qu’une sémantique explicite améliore la compréhension du système. Avec des
messages génériques, il faut analyser leur contenu pour comprendre l’intention
réelle et déterminer la réaction appropriée. On finit souvent par déléguer vers
différentes méthodes en fonction des données du message.

Dans un système event-sourced, des événements spécifiques ont l'avantage de
rendre l’historique plus lisible : on comprend clairement ce qui s’est produit et quelles réactions chaque événement déclenche.

// À é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
de messages. C’est vrai. Mais quel est le problème ?

Une classe supplémentaire n’aura aucun impact significatif sur les performances
du système. En revanche, elle améliorera fortement sa lisibilité, sa
maintenabilité et son explicitation métier.

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.