Contrat du Repository Product¶

Statut¶

Spécification normative du domaine métier Product.

À quoi sert un Repository ?¶

Un Repository est une frontière entre le domaine métier et la persistance.

Le domaine Product a besoin de pouvoir enregistrer et retrouver un Product, mais il ne doit pas connaître les détails techniques permettant de le faire.

Le Repository exprime donc des intentions comme :

retrouver un Product
sauvegarder un Product

sans exposer :

SELECT ...
UPDATE ...
nom_de_table
$wpdb

Principe central¶

Le Repository ne doit jamais violer les invariants du Product.

Cela signifie notamment qu'il ne doit pas persister un état qui serait considéré comme invalide par le domaine.

Invariants à préserver¶

un Product possède une seule identité canonique ;
un identifiant reste une preuve, pas une identité à lui seul ;
une observation ne remplace pas silencieusement l'identité ;
une variante appartient à exactement un Product.

Ce que le Repository doit faire¶

Il doit :

persister le Product comme un agrégat cohérent ;
le retrouver avec un état suffisamment complet pour continuer le raisonnement métier ;
préserver ses invariants pendant toute opération de persistance.

Ce qu'il ne doit pas faire¶

Il ne doit pas :

sauvegarder une partie du Product en laissant volontairement le reste incohérent ;
contourner la racine d'agrégat Product pour modifier directement un sous-élément métier ;
décider de l'identité ;
inventer ou interpréter une règle métier ;
imposer une structure SQL au domaine ;
dépendre de WordPress ;
dépendre du format d'un feed marchand.

Exemple concret¶

Supposons qu'un Product possède :

identité canonique
+ variantes
+ observations
+ conflits éventuels
+ état de cohérence

Le Repository ne doit pas sauvegarder seulement le nom du modèle et oublier un conflit qui fait partie de l'état métier nécessaire.

Sinon, lorsqu'on relira le Product, il ne représentera plus le même état métier.

Repository et SQL : quelle différence ?¶

Le contrat Repository appartient au monde métier.

L'implémentation concrète peut utiliser MariaDB et SQL, mais ces détails restent dans la couche d'infrastructure.

Domain Product
    ↓
ProductRepository (contrat)
    ↓
Implémentation technique
    ↓
MariaDB / stockage

Cette séparation permet de modifier la façon de stocker les données sans devoir réécrire les règles Product.

Comment diagnostiquer un problème de persistance¶

Si un Product est correct avant sauvegarde mais incorrect après relecture :

vérifier l'état du Product avant persistance ;
vérifier ce que l'implémentation du Repository écrit réellement ;
relire le Product via le même contrat ;
comparer les deux états ;
identifier précisément l'information perdue ou modifiée.

Ne corrige pas immédiatement la table SQL à la main : il faut d'abord déterminer si le défaut vient du domaine, du mapping de persistance ou de la donnée déjà stockée.

Pour une personne qui reprend le projet¶

Quand tu vois Repository, pense :

« porte d'accès métier au stockage »

et non :

« classe qui contient forcément du SQL ».

Le SQL est un détail de l'implémentation. Le contrat Repository décrit ce que le domaine attend.

Décision¶

Le Repository Product est un contrat pur tourné vers le domaine.