Aller au contenu

Événements du domaine Product

Statut

Spécification normative du domaine métier Product.

À quoi sert cette page ?

Cette page explique les Domain Events du domaine Product.

Un Domain Event représente un changement métier important qui vient réellement de se produire.

Exemple : lorsqu'une identité canonique est établie pour un produit, ce changement peut être représenté par ProductIdentityEstablished.

Un événement métier ne décrit pas une opération technique comme « une requête SQL a été exécutée » ou « un cache a été vidé ». Il décrit ce que le métier considère comme significatif.

Règle principale

Un événement du domaine Product ne doit être produit que lorsque l'état métier change.

Il ne doit pas représenter :

  • une écriture SQL ;
  • une invalidation de cache ;
  • un rendu frontend ;
  • un log ;
  • une exécution Runtime ;
  • une synchronisation d'Adapter.

Pourquoi utiliser des événements ?

Ils permettent de conserver un vocabulaire clair sur les changements importants.

Au lieu de dire « tel champ a été modifié », on peut dire précisément :

  • un produit a été découvert ;
  • une identité a été établie ;
  • une observation a été attachée ;
  • un conflit a été détecté ;
  • une identité canonique a changé.

Cela facilite les audits, les tests et la compréhension de l'historique métier.

Événements définis

ProductDiscovered

Émis lorsqu'un nouveau candidat produit est découvert.

Attention : « découvert » ne signifie pas forcément que son identité canonique est déjà résolue.

ProductIdentityEstablished

Émis lorsque l'identité canonique d'un produit est établie.

Cet événement marque une décision métier importante et doit rester traçable.

ProductIdentifierAttached

Émis lorsqu'un nouvel identifiant est attaché comme preuve.

L'événement n'affirme pas que l'identifiant est la vérité ; seulement qu'il a été ajouté aux preuves disponibles.

ProductObservationAttached

Émis lorsqu'une observation est rattachée à un produit.

ProductVariantDiscovered

Émis lorsqu'une nouvelle variante du produit est découverte.

ProductConflictDetected

Émis lorsqu'une contradiction apparaît entre les preuves, l'identité, les identifiants ou les variantes.

Cet événement est important : un conflit ne doit pas être masqué silencieusement.

ProductConflictResolved

Émis lorsqu'une résolution explicite permet de clôturer un conflit.

Le simple fait qu'un nouveau score soit plus élevé ne suffit pas nécessairement à considérer le conflit comme résolu : la politique correspondante doit être respectée.

ProductConsistencyChanged

Émis lorsque l'état de cohérence du produit change.

Par exemple :

incomplete → consistent
consistent → conflicting

ProductCanonicalIdentityChanged

Émis uniquement lorsque l'identité canonique elle-même change.

Cet événement doit rester exceptionnel, explicite et auditable car changer l'identité d'un produit peut avoir des conséquences sur les variantes, projections et consommateurs aval.

Exemple concret

Supposons qu'une nouvelle observation Samsung arrive :

Observation reçue
       ↓
Attachée au Product
       ↓
ProductObservationAttached
       ↓
Nouvel identifiant cohérent détecté
       ↓
ProductIdentifierAttached
       ↓
Les preuves permettent enfin une résolution
       ↓
ProductIdentityEstablished

Si au contraire le nouvel identifiant contredit la marque déjà établie :

Nouvelle preuve
       ↓
Contradiction
       ↓
ProductConflictDetected

Cette différence doit rester visible dans le système.

Propriétés attendues

Les événements doivent être :

  • déterministes ;
  • traçables ;
  • sérialisables ;
  • indépendants de l'infrastructure ;
  • indépendants des adapters.

Sérialisable signifie que l'événement peut être représenté sous une forme stable — par exemple pour le stockage, un audit ou un replay — sans dépendre d'un objet technique impossible à reconstruire.

Signaux d'alerte

Il faut se méfier si un événement :

  • contient directement un objet WordPress ;
  • dépend d'une connexion SQL ;
  • décrit uniquement une action technique ;
  • est émis alors qu'aucun état métier n'a changé ;
  • masque un changement important derrière un nom générique comme ProductUpdated sans raison précise.

Décision d'architecture

Décision : CERTIFIED.

Les événements du domaine Product décrivent exclusivement les changements métier importants et jamais les effets techniques secondaires.

Voir aussi