Domaine métier Product — vue d'ensemble¶

Statut¶

Point d'entrée normatif du domaine métier Product.

Cette page décrit ce que CMonChoix considère comme un produit et où cette vérité métier doit vivre.

Pourquoi ce domaine existe¶

Un marchand publie une offre. CMonChoix, lui, doit comprendre quel produit réel se trouve derrière cette offre.

Ces deux notions sont différentes :

Offre marchand
   ↓
Observation sur un produit
   ↓
Preuves et identifiants
   ↓
Résolution
   ↓
Produit canonique

Un produit ne doit donc pas être défini par son prix, sa disponibilité, son titre marchand ou sa page WordPress. Ces éléments peuvent changer alors que le produit reste le même.

Le domaine Product protège cette distinction.

Ce que le domaine Product possède¶

Il est responsable notamment de :

l'identité d'un produit ;
l'identité canonique ;
les variantes ;
les observations ;
les identifiants ;
les preuves ;
les conflits ;
l'état de cohérence.

Ce qu'il ne possède pas¶

Le domaine Product ne doit pas contenir :

les offres commerciales ;
les prix ;
les promotions ;
le stock ;
la navigation du catalogue ;
le rendu frontend ;
le SEO ;
le parsing d'un feed ;
le schéma SQL ;
la logique WordPress ;
l'orchestration Runtime.

Pourquoi ? Parce que ces responsabilités changent pour des raisons différentes. Les mélanger rendrait impossible de savoir où corriger un problème.

Exemple concret¶

Imaginons deux marchands :

Marchand A : Samsung Galaxy S26 Noir 256 Go
Marchand B : Galaxy S26 256GB Black

Les textes diffèrent, mais ils peuvent désigner le même produit et la même variante.

Le domaine Product doit conserver les observations et preuves, puis permettre une résolution explicable. Il ne doit pas décider que les produits sont identiques uniquement parce que leurs titres se ressemblent.

Les concepts principaux¶

Product¶

Product représente le produit métier stable.

Ce n'est ni une offre, ni une ligne de feed, ni une fiche WordPress.

Canonical Product Identity¶

La Canonical Product Identity est l'identité stable retenue comme référence officielle du produit.

Observation¶

Une Observation est une information reçue ou dérivée d'une source : titre, marque, identifiant, attribut technique, etc.

Une observation constitue une preuve potentielle, pas automatiquement la vérité finale.

Evidence¶

Une Evidence est une information utilisée pour soutenir ou contredire une décision d'identité.

Variant¶

Une Variant représente une version du même produit ayant des attributs distinctifs : couleur, stockage, mémoire, taille, etc.

Conflict¶

Un Conflict représente une contradiction explicite entre plusieurs preuves.

Un conflit ne doit jamais être caché pour forcer une résolution.

Qu'est-ce qu'un Aggregate ?¶

Dans le vocabulaire DDD (Domain-Driven Design), un Aggregate est un ensemble d'objets métier qui doivent rester cohérents ensemble.

Ici, Product est l'Aggregate Root, c'est-à-dire le point d'entrée chargé de protéger cette cohérence.

Par exemple, une modification de l'identité ou l'ajout d'une variante ne doit pas contourner Product en modifiant directement un objet interne au hasard.

Voir Aggregate Product.

Qu'est-ce qu'un Value Object ?¶

Un Value Object est un petit objet métier défini par sa valeur et généralement immuable.

Exemples :

ProductId ;
Brand ;
ModelName ;
ConfidenceScore.

Deux Value Objects représentant exactement la même valeur sont conceptuellement équivalents, contrairement à une entité dont l'identité propre compte.

Qu'est-ce qu'une Entity ?¶

Une Entity est un objet métier possédant une identité qui reste importante dans le temps.

Le domaine Product utilise notamment des concepts tels que Product, ProductVariant ou ProductObservation.

Events¶

Les Domain Events décrivent quelque chose d'important qui vient de se produire dans le métier, par exemple :

ProductDiscovered ;
ProductIdentityEstablished ;
ProductConflictDetected.

Ils permettent de représenter explicitement les changements significatifs plutôt que de les cacher dans des effets de bord.

Policies et Specifications¶

Une Policy décrit une règle ou une stratégie métier, par exemple la manière de traiter un conflit.

Une Specification décrit généralement une condition métier vérifiable : identité suffisamment complète, variante valide, conflit détecté, etc.

Ces noms restent en anglais dans le code lorsqu'ils correspondent aux vrais concepts techniques, mais leur rôle est celui-ci.

Contracts¶

Les Contracts définissent comment les autres couches collaborent avec le domaine sans dépendre de ses détails internes.

Exemples :

ProductRepository ;
ProductIdentityResolver ;
ProductFactory ;
ProductConsistencyPolicy.

Repository¶

Un Repository fournit une abstraction permettant de retrouver ou sauvegarder des objets métier sans faire du domaine lui-même un composant SQL.

Factory¶

Une Factory centralise la création d'un objet lorsque cette création doit garantir plusieurs règles ou invariants.

Query¶

Une Query exprime une intention de lecture. Elle ne doit pas devenir une écriture déguisée.

Projection¶

Une Projection est une vue dérivée destinée à la lecture ou à un consommateur précis. Elle ne remplace pas la vérité du domaine Product.

Invariants essentiels¶

Les règles les plus importantes sont :

un Product possède exactement une identité canonique dans son périmètre ;
un identifiant constitue une preuve, pas une identité à lui seul ;
une observation ne modifie pas silencieusement l'identité ;
une variante appartient à un seul Product ;
un conflit réel reste visible et explicable.

Comment diagnostiquer un problème Product¶

Si deux offres semblent mal regroupées ou si une identité paraît fausse, ne corrige pas d'abord le frontend.

Suis plutôt ce chemin :

Symptôme visible
   ↓
Quelle projection est affichée ?
   ↓
Quel Product est référencé ?
   ↓
Quelle identité canonique est retenue ?
   ↓
Quelles observations / preuves l'ont produite ?
   ↓
Y a-t-il unknown / ambiguous / conflict ?
   ↓
Corriger la règle ou la donnée au niveau responsable

Cette méthode permet d'éviter un correctif local qui masquerait une erreur d'identité en amont.

Ordre de lecture recommandé¶

Pour découvrir le domaine sans connaissance préalable :

Il n'est pas nécessaire de tout mémoriser. Le point essentiel est de savoir quel concept possède quelle responsabilité.

Garantie d'architecture¶

Le domaine Product doit rester indépendant :

de SQL ;
de WordPress ;
des feeds ;
du frontend ;
du Runtime.

Les détails techniques peuvent collaborer avec lui via des contrats, mais ne doivent pas redéfinir sa vérité métier.

Décision d'architecture¶

Décision : CERTIFIED.

Cette page est le point d'entrée officiel du Product Domain et sert de référence pour les futurs domaines liés au catalogue, aux offres, aux projections, aux prix et à l'identité.