Contrats du domaine Product¶
Statut¶
Spécification normative du domaine métier Product.
Pourquoi cette page existe¶
Un contrat décrit ce qu'un composant doit savoir faire sans imposer la manière technique de le faire.
Dans CMonChoix, cette séparation est essentielle : le domaine Product doit pouvoir exprimer ses besoins sans dépendre directement de SQL, WordPress, Docker, HTTP ou d'un autre détail d'infrastructure.
Autrement dit, le domaine dit « j'ai besoin de retrouver un Product » ; l'infrastructure décide ensuite comment cette recherche est réellement exécutée.
À quoi sert un contrat ?¶
Un contrat permet de fixer :
- la responsabilité d'un composant ;
- ce qu'il reçoit ;
- ce qu'il doit garantir ;
- les erreurs ou états qu'il doit rendre explicites ;
- les dépendances qu'il n'a pas le droit d'introduire.
Cette discipline permet de remplacer une implémentation sans réécrire toute la logique métier.
ProductRepository¶
ProductRepository définit la manière dont le domaine demande à enregistrer ou retrouver un agrégat Product.
Le contrat ne doit pas exposer :
- de nom de table ;
- de requête SQL ;
- de fonction WordPress ;
- de détail de cache ;
- de chemin de fichier.
Exemple mental¶
Le domaine peut demander :
Donne-moi le Product correspondant à cet identifiant interne.
Il ne doit pas avoir besoin de savoir si l'information provient d'une table MariaDB, d'un cache ou d'une autre implémentation future.
ProductIdentityResolver¶
Le ProductIdentityResolver établit ou confirme l'identité canonique d'un produit à partir de preuves.
Sa résolution doit rester :
- déterministe ;
- traçable ;
- explicable ;
- reproductible.
Il ne doit pas transformer silencieusement un cas ambigu en résultat certain.
ProductFactory¶
La ProductFactory crée un nouvel agrégat Product dans un état initial valide.
Une Factory est simplement un composant spécialisé dans la création correcte d'un objet métier complexe.
Son intérêt est d'éviter que plusieurs endroits du code créent des Products de manières légèrement différentes.
ProductConsistencyPolicy¶
Cette politique évalue si un Product est cohérent à partir de :
- son identité ;
- ses identifiants ;
- ses observations ;
- ses variantes ;
- ses conflits.
Elle ne persiste rien elle-même.
ProductVariantPolicy¶
Cette politique décide si des attributs décrivent une variante du même Product ou un autre Product.
Exemple : une différence de couleur peut être une variante, alors qu'un modèle totalement différent ne doit pas être rattaché au même Product.
La décision exacte dépend des règles métier certifiées.
ProductObservationNormalizer¶
Ce contrat prépare une observation pour qu'elle puisse être évaluée par le domaine Product.
Il ne doit pas contenir le parsing propre à un feed marchand précis. Les particularités de source doivent rester dans les couches prévues pour l'ingestion et le mapping.
Règles générales¶
Les contrats Product doivent employer le vocabulaire du domaine Product.
Ils ne doivent pas dépendre directement de :
- SQL ;
- WordPress ;
- Docker ;
- CLI ;
- HTTP ;
- frontend ;
- cache ;
- jobs Runtime.
Comment reconnaître une mauvaise implémentation¶
Un signal d'alerte apparaît si une interface du domaine contient des éléments comme :
table_name
wpdb
HTTP response
WP_CLI
Docker container
Cela signifie probablement qu'un détail technique a traversé une frontière qui devait rester métier.
Pour une personne qui reprend le projet¶
Quand tu rencontres un nom comme ProductRepository ou ProductIdentityResolver, ne cherche pas d'abord son SQL ou son fichier concret.
Commence par répondre à ces questions :
- Quel besoin métier ce contrat exprime-t-il ?
- Quelles garanties doit-il fournir ?
- Quelle implémentation concrète l'utilise dans le runtime actuel ?
- Cette implémentation respecte-t-elle toujours les invariants Product ?
Cette méthode évite de confondre ce que le système doit faire avec la manière dont il le fait aujourd'hui.
Décision d'architecture¶
Décision : CERTIFIED.
Les contrats Product sont les points d'intégration officiels du domaine tout en préservant son indépendance vis-à-vis de l'infrastructure.