Politiques du domaine Product¶
Statut¶
Spécification normative du domaine métier Product.
À quoi sert cette page ?¶
Les Policies du domaine Product décrivent les décisions métier qui protègent l'identité et la cohérence des produits.
Une policy n'est pas une préférence de présentation ni une règle technique. C'est une règle de décision métier qui doit rester vraie quelle que soit la manière dont les données sont stockées ou affichées.
Politique d'identité canonique¶
Un Product possède une seule identité canonique dans son périmètre.
L'identité peut rester incomplète pendant la phase de découverte, mais cette situation doit être explicite.
Un remplacement silencieux d'identité est interdit.
Exemple¶
Si un produit est actuellement identifié comme Samsung Galaxy S26, une nouvelle observation ne doit pas le transformer automatiquement en Samsung Galaxy S26 Ultra simplement parce qu'un titre marchand contient le mot Ultra.
La nouvelle preuve doit être évaluée, et un conflit éventuel doit rester visible.
Politique sur les identifiants¶
Les identifiants sont des preuves.
Aucun identifiant ne définit, à lui seul et sans contrôle, la vérité produit.
Si plusieurs identifiants se contredisent, un conflit doit être créé au lieu de choisir arbitrairement l'un d'eux.
Politique sur les observations¶
Les observations sont également des preuves.
Une observation peut :
- soutenir une identité ;
- enrichir un produit ;
- remettre en question une identité existante.
Elle ne doit jamais écraser directement l'identité canonique.
Politique de propriété des variantes¶
Une ProductVariant appartient à exactement un Product.
Une variante ne doit pas être partagée entre plusieurs produits.
Si des attributs semblent appartenir à plusieurs produits différents, la cause doit être résolue au niveau de l'identité ou des règles de variante.
Politique de visibilité des conflits¶
Toute contradiction entre preuves doit devenir un ProductConflict explicite.
Une résolution cachée est interdite.
Exemples de conflits :
- marque incompatible ;
- modèle incompatible ;
- famille produit contradictoire ;
- identifiants fiables incompatibles.
Un conflit ne disparaît pas parce qu'un score global reste élevé.
Politique de cohérence¶
L'état de cohérence d'un produit doit être dérivé à partir de plusieurs dimensions :
- complétude de l'identité ;
- cohérence des identifiants ;
- cohérence des observations ;
- cohérence des variantes ;
- présence de conflits non résolus.
Cela évite de réduire la qualité d'un produit à un seul indicateur.
Politique de frontière¶
Le domaine Product doit rejeter les concepts qui appartiennent à d'autres responsabilités :
- Offer ;
- Catalog ;
- Projection ;
- Pipeline ;
- Runtime ;
- Adapter ;
- Infrastructure.
Pourquoi cette règle est importante¶
Si une règle de prix ou de stock entre dans Product, le domaine devient dépendant d'informations commerciales qui changent beaucoup plus souvent que l'identité du produit.
Inversement, si une règle d'identité est déplacée vers le frontend, on crée une deuxième vérité métier.
Comment utiliser une policy pendant un diagnostic¶
Si un produit paraît incohérent :
- identifie quelle policy devrait protéger la situation ;
- vérifie les preuves disponibles ;
- vérifie si le conflit attendu a été créé ;
- vérifie quelle couche a modifié l'état ;
- corrige la règle ou le chemin responsable plutôt que la projection finale.
Signaux d'alerte¶
Une modification mérite une revue d'architecture si elle propose de :
- remplacer automatiquement une identité avec une seule observation ;
- considérer un EAN comme infaillible ;
- cacher un conflit derrière un score ;
- rattacher une variante à plusieurs produits ;
- ajouter prix, stock ou navigation aux règles Product ;
- corriger une incohérence directement dans le frontend ou la base.
Décision d'architecture¶
Décision : CERTIFIED.
Les policies du domaine Product définissent les règles de décision métier qui doivent être appliquées avant l'implémentation technique.