Requêtes du Product Domain¶

Statut¶

Spécification métier normative de lecture.

Qu'est-ce qu'une Query ?¶

Une Query décrit une intention de lecture : elle exprime ce que l'on veut obtenir, sans imposer la manière dont les données sont stockées.

Exemple :

retrouver un Product à partir d'un identifiant.

Cette intention est métier. La manière de la réaliser peut utiliser SQL, un index, un cache ou une autre technologie sans modifier la Query elle-même.

Règle centrale¶

Une Query est read-only : elle lit, elle ne modifie rien.

Elle ne doit donc jamais provoquer de changement d'identité, d'ajout de variante, de correction de conflit ou d'écriture en base.

Invariants concernés¶

Les lectures doivent respecter les règles du Product Domain :

un Product possède une identité canonique unique ;
un Identifier reste une preuve ;
une Observation ne modifie pas l'identité ;
une Variant appartient à un seul Product.

Types de requêtes¶

Requêtes d'identité¶

Elles servent par exemple à :

retrouver un Product par ProductId ;
retrouver un Product par identité canonique ;
retrouver les Products associés à un Identifier.

Requêtes de cohérence¶

Elles permettent de rechercher :

les Products ayant des conflits ;
les Products dont l'identité est incomplète ;
les Products dont le niveau de confiance est faible.

Requêtes de structure¶

Elles permettent de lister :

les variantes d'un Product ;
les observations associées ;
les identifiants connus.

Query, Repository et Projection : ne pas les confondre¶

Query       → exprime la question
Repository  → fournit l'accès métier aux données
Projection  → prépare une vue optimisée pour un usage de lecture

Une Query peut être satisfaite par un Repository ou une projection dédiée selon le besoin. Mais la Query elle-même ne doit pas dépendre de la structure SQL.

Exemple concret¶

Pour afficher les Products ayant un conflit d'identité, l'intention peut être :

FindProductsWithConflicts

L'implémentation peut ensuite utiliser une projection ou une requête optimisée. Le contrat métier reste : retourner les Products concernés sans les modifier.

Règles¶

Les Queries doivent :

être en lecture seule ;
rester indépendantes des tables SQL ;
ne pas dépendre de WordPress ;
ne pas dépendre des feeds marchands ;
produire un résultat reproductible lorsque les données source ne changent pas.

Pour diagnostiquer une mauvaise lecture¶

Si une page ou un audit ne retrouve pas le bon Product :

identifier la Query ou le besoin de lecture ;
vérifier la source utilisée pour répondre à cette Query ;
vérifier si une projection est obsolète ;
comparer la donnée canonique avec la vue de lecture ;
ne pas modifier le Product uniquement parce qu'une vue de lecture est incorrecte.

Décision¶

Les Queries définissent l'intention de lecture, pas la manière dont les données sont stockées.