Aller au contenu

Objets valeur du domaine Product

Statut

Spécification normative du domaine métier Product.

À quoi sert cette page ?

Cette page explique les Value Objects du domaine Product.

Un Value Object est un petit objet métier défini par sa valeur, et non par une identité propre. Deux Value Objects contenant exactement la même valeur sont donc considérés comme équivalents.

Exemple simple :

  • la marque Samsung est une valeur ;
  • le modèle Galaxy S26 est une valeur ;
  • un produit précis possède, lui, une identité propre et un cycle de vie.

Les Value Objects servent à empêcher que des concepts importants soient manipulés comme de simples chaînes de caractères sans règle.

Règles générales

Les Value Objects du domaine Product doivent être :

  • immutables : une fois créés, leur valeur ne change pas ;
  • comparables par leur contenu ;
  • valides dès leur création ;
  • indépendants de WordPress, SQL, du frontend et de l'infrastructure.

Un Value Object ne doit donc pas effectuer une requête SQL, lire $_POST, ou dépendre d'un conteneur Docker.

ProductId

ProductId identifie un agrégat Product dans la plateforme.

Il s'agit de l'identifiant interne du produit dans le domaine, et non d'un identifiant fourni par un marchand.

À ne pas confondre avec :

  • un EAN ;
  • un SKU marchand ;
  • un identifiant de ligne de feed ;
  • une clé primaire SQL.

Une fois attribué, ProductId doit rester stable.

CanonicalProductIdentity

CanonicalProductIdentity représente l'identité métier officielle et stable du produit.

Elle peut contenir des concepts comme :

  • Brand ;
  • ModelName ;
  • Series ;
  • Generation ;
  • ProductFamily ;
  • ProductType.

Elle ne doit pas contenir :

  • prix ;
  • stock ;
  • marchand ;
  • feed ;
  • titre SEO ;
  • libellé frontend ;
  • clé primaire SQL.

Pourquoi ? Parce que ces informations peuvent évoluer sans que le produit réel change d'identité.

Brand

Brand représente la marque commerciale ou le fabricant.

La valeur doit être suffisamment normalisée pour permettre des comparaisons fiables.

Exemple : selon la politique de normalisation, SAMSUNG, Samsung et samsung ne doivent pas devenir trois marques métier différentes.

ModelName

ModelName représente le nom de modèle commercial.

Il doit éviter autant que possible le bruit marketing propre aux marchands.

Exemple :

Titre marchand : Samsung Galaxy S26 256 Go Noir - Offre exceptionnelle
ModelName      : Galaxy S26

Le prix, la couleur et le texte promotionnel n'ont pas à polluer le nom de modèle canonique.

Series

Series représente une gamme ou une famille commerciale de modèles.

Exemples :

  • iPhone ;
  • Galaxy S ;
  • PlayStation ;
  • EOS ;
  • ThinkPad.

Une série n'est pas forcément un modèle précis.

Generation

Generation décrit une génération, une année, une édition ou une version lorsque cela a un sens dans la famille de produits.

Cette valeur reste optionnelle : tous les produits n'ont pas une notion de génération explicite.

ProductFamily

ProductFamily regroupe les produits dans une famille métier stable.

Exemples :

  • smartphone ;
  • tablette ;
  • imprimante ;
  • appareil photo.

Ce n'est pas une catégorie de navigation du site. Une catégorie frontend peut évoluer pour des raisons d'expérience utilisateur sans modifier la famille métier du produit.

ProductType

ProductType décrit ce qu'est le produit en termes métier génériques.

Il doit rester stable et indépendant de la taxonomie d'un marchand.

Identifier

Identifier représente un signal d'identification.

Exemples :

  • EAN ;
  • GTIN ;
  • MPN ;
  • SKU ;
  • identifiant produit marchand ;
  • référence fabricant ;
  • référence modèle.

Un identifiant est une preuve, pas automatiquement la vérité.

Exemple : un EAN mal fourni par un marchand ne doit pas pouvoir fusionner deux produits incompatibles sans contrôle.

IdentifierType

IdentifierType indique le type d'identifiant.

Le type doit être explicite afin que le système sache quelle confiance et quelles règles appliquer.

Un identifiant de type inconnu ne doit jamais être silencieusement traité comme un identifiant hautement fiable.

VariantAttributes

VariantAttributes contient les attributs qui distinguent plusieurs variantes d'un même produit.

Exemples :

  • couleur ;
  • stockage ;
  • mémoire ;
  • taille ;
  • réseau ;
  • finition.

Ces attributs ne doivent pas contenir prix, stock ou marchand.

Exemple

Produit canonique : Galaxy S26

Variante A :
- stockage : 128 Go
- couleur : noir

Variante B :
- stockage : 256 Go
- couleur : noir

Ces deux variantes peuvent appartenir au même produit selon le contrat de la verticale concernée.

ConfidenceScore

ConfidenceScore représente le niveau de confiance associé à une décision d'identité.

Un score n'a jamais le droit de masquer un conflit explicite.

Par exemple, un score élevé ne doit pas transformer deux marques incompatibles en correspondance valide simplement parce que d'autres signaux sont proches.

ConsistencyStatus

ConsistencyStatus représente l'état de cohérence métier du produit.

Les états conceptuels prévus sont :

  • consistent : cohérent ;
  • incomplete : informations insuffisantes ;
  • conflicting : contradictions présentes ;
  • unresolved : identité non résolue.

Ces états doivent rester explicites pour permettre les audits et diagnostics.

Comment savoir si quelque chose doit devenir un Value Object ?

Pose ces questions :

  1. Est-ce un concept métier ayant ses propres règles ?
  2. Deux valeurs identiques doivent-elles être considérées comme équivalentes ?
  3. Ce concept n'a-t-il pas besoin d'un cycle de vie autonome ?
  4. Veut-on empêcher des valeurs invalides d'entrer dans le domaine ?

Si oui, un Value Object est probablement adapté.

Signaux d'alerte

Il faut se méfier si :

  • une chaîne brute traverse plusieurs couches alors qu'elle représente un concept métier important ;
  • un Value Object commence à faire du SQL ;
  • une valeur peut devenir invalide après sa création ;
  • un champ marchand est ajouté directement dans CanonicalProductIdentity ;
  • une catégorie frontend est utilisée comme ProductFamily.

Décision d'architecture

Décision : CERTIFIED.

Les Value Objects définissent le vocabulaire immuable du domaine Product avant les entités, événements et contrats.

Ils protègent le domaine contre les fuites de concepts venant de l'infrastructure, des marchands ou du frontend.

Voir aussi