Aller au contenu

Entités du domaine Product

Statut

Spécification normative du domaine métier Product.

À quoi sert cette page ?

Cette page explique les Entities du domaine Product.

Une Entity est un objet métier qui possède une identité propre et un cycle de vie. Contrairement à un Value Object, deux entités ayant les mêmes valeurs ne sont pas forcément la même chose.

Exemple simple : deux produits peuvent avoir temporairement les mêmes libellés, mais ils restent deux entités distinctes tant que leur identité métier n'a pas été résolue comme identique.

Product

Product est l'Aggregate Root du domaine Product.

Cela signifie que les modifications importantes concernant l'identité, les variantes, les observations et les conflits doivent passer par lui.

Product possède notamment :

  • l'identité canonique ;
  • les identifiants ;
  • les observations ;
  • les variantes ;
  • les conflits ;
  • l'état de cohérence.

Le but est d'empêcher qu'un composant extérieur modifie une partie sensible du produit sans faire respecter les invariants du domaine.

ProductVariant

ProductVariant représente une version du même produit avec des attributs distinctifs.

Exemples :

  • Galaxy S26 128 Go noir ;
  • Galaxy S26 256 Go noir ;
  • même modèle de téléviseur en 55 et 65 pouces, si la verticale définit la taille comme variante.

Une variante appartient à exactement un Product.

ProductObservation

ProductObservation représente une information reçue, extraite ou déduite depuis une source.

Exemples :

  • un titre marchand ;
  • une marque annoncée ;
  • un EAN ;
  • une capacité de stockage ;
  • une référence fabricant.

Une observation est une preuve. Elle n'a pas le droit de remplacer directement l'identité canonique.

ProductIdentifierSet

ProductIdentifierSet regroupe les identifiants associés à un produit ou à une observation.

Son rôle est de protéger la cohérence des identifiants et d'éviter qu'ils soient manipulés comme une simple liste sans règles.

ProductEvidence

ProductEvidence représente une preuve traçable utilisée dans une décision d'identité ou de cohérence.

Une preuve doit rester auditable : il faut pouvoir comprendre d'où elle vient et pourquoi elle a été utilisée.

ProductConflict

ProductConflict représente une contradiction explicite entre plusieurs preuves.

Exemples :

  • même EAN mais marques différentes ;
  • même modèle mais familles produit incompatibles ;
  • observation fiable contredisant l'identité canonique actuelle.

Un conflit doit être visible, traçable et résoluble. Il ne doit jamais être masqué par une valeur par défaut.

Règles communes aux entités

Les entités du domaine Product ne doivent pas dépendre de :

  • SQL ;
  • WordPress ;
  • frontend ;
  • feeds ;
  • Runtime ;
  • cache ;
  • HTTP.

Elles représentent le métier, pas la manière technique dont celui-ci est stocké ou affiché.

Exemple de diagnostic

Si un produit semble avoir reçu une mauvaise variante, ne corrige pas directement une table SQL.

Cherche plutôt :

  1. quelle ProductObservation a introduit l'information ;
  2. quelle ProductEvidence a été retenue ;
  3. si un ProductConflict aurait dû être créé ;
  4. quelle règle a attaché la ProductVariant au Product.

Cette remontée permet de corriger la cause plutôt que le symptôme.

Décision d'architecture

Décision : CERTIFIED.

Les entités Product représentent les objets ayant une identité et un cycle de vie à l'intérieur de l'agrégat Product.

Voir aussi