Quality¶

Vue d'ensemble¶

Le module Quality est responsable de l'évaluation de la qualité des informations associées à une Canonical Product Identity.

Son rôle n'est pas de déterminer l'identité d'un produit — cette responsabilité appartient au Resolver — mais d'évaluer la fiabilité des informations qui composent cette identité une fois la résolution terminée.

Le résultat est un ensemble d'indicateurs génériques, réutilisables par l'ensemble de la Platform.

Le module ne connaît aucune verticale métier. Il applique exclusivement des règles génériques pouvant être partagées entre les smartphones, les appareils photo, les imprimantes, les téléviseurs ou toute future famille de produits.

Objectifs¶

Le module poursuit plusieurs objectifs :

mesurer la qualité globale d'une identité produit ;
détecter les informations incomplètes ou incohérentes ;
produire des indicateurs exploitables par les autres composants de la Platform ;
fournir une base commune pour le suivi de la qualité des données.

Il ne cherche jamais à corriger les données ni à prendre une décision métier.

Position dans l'architecture¶

Le module intervient après la résolution de l'identité canonique.

Candidate
        │
        ▼
Resolver
        │
        ▼
Canonical Identity
        │
        ▼
Quality
        │
        ▼
Projection

À ce stade, les différentes sources marchandes ont déjà été rapprochées et les identifiants normalisés.

Quality travaille donc sur une représentation stable du produit.

Responsabilités¶

Le module est responsable de l'évaluation de plusieurs dimensions.

Complétude¶

La première consiste à mesurer la complétude des informations disponibles.

Par exemple :

marque connue ;
modèle identifié ;
identifiants présents ;
caractéristiques techniques disponibles ;
attributs principaux renseignés.

L'objectif n'est pas d'imposer une quantité minimale d'informations, mais de mesurer objectivement ce qui est disponible.

Cohérence¶

Le module vérifie également la cohérence des informations.

Quelques exemples :

plusieurs marchands indiquent la même marque ;
les différents identifiants ne se contredisent pas ;
le modèle est compatible avec la famille détectée ;
les informations techniques restent cohérentes entre elles.

Lorsqu'une incohérence est détectée, elle est signalée.

Le module ne tente jamais de la résoudre.

Confiance¶

Quality expose également un niveau de confiance construit à partir des informations disponibles.

Cette confiance peut notamment prendre en compte :

le nombre d'identifiants concordants ;
la qualité des informations collectées ;
la stabilité de la résolution ;
la cohérence globale des données.

Ces indicateurs pourront être exploités par d'autres composants de la Platform.

Ce que le module ne fait jamais¶

Le module Quality ne doit jamais :

résoudre une identité produit ;
modifier les données ;
choisir entre plusieurs candidats ;
appliquer une règle spécifique à une verticale ;
accéder directement au Frontend ;
exécuter des traitements Runtime.

Ces responsabilités appartiennent à d'autres composants.

Invariants¶

Les règles suivantes doivent toujours être respectées.

Aucune connaissance métier¶

Quality ne connaît jamais :

Smartphone ;
Photo ;
TV ;
Gaming ;
Printer ;
Mobility ;
Toys.

Toutes les règles doivent rester génériques.

Si une règle ne fonctionne que pour une seule verticale, elle n'a pas sa place dans ce module.

Déterminisme¶

À données identiques, le résultat doit toujours être identique.

Le calcul de la qualité ne dépend ni de l'ordre d'exécution, ni du contexte d'appel.

Lecture seule¶

Le module n'effectue aucune modification.

Il observe.

Il mesure.

Il produit des indicateurs.

Toute correction appartient à un autre composant.

Indépendance¶

Le module dépend uniquement des contrats stables du Domain Core.

Il ne dépend jamais :

du Frontend ;
du Runtime ;
du Pipeline ;
d'une verticale métier.

Cette indépendance garantit sa réutilisabilité.

Consommateurs¶

Les informations produites par Quality peuvent être utilisées par :

Projection ;
Read Services ;
outils d'audit ;
rapports de validation ;
tableaux de bord ;
futurs Write Services.

Le Frontend ne consomme jamais directement le module.

Il utilise uniquement les projections préparées en amont.

Exemple¶

Deux marchands décrivent le même smartphone.

Le Resolver construit une Canonical Product Identity unique.

Quality peut alors constater que :

les deux marchands indiquent la même marque ;
les références constructeur correspondent ;
un EAN est présent ;
les caractéristiques techniques sont complètes.

Le module produit alors un ensemble d'indicateurs décrivant une identité de bonne qualité.

À l'inverse, si les identifiants sont absents ou contradictoires, Quality signale simplement une qualité plus faible.

Il ne décide jamais quelle information est correcte.

Évolution¶

Le module a vocation à devenir le point central de toutes les métriques de qualité de la Platform.

À mesure que de nouvelles verticales seront industrialisées, les règles réellement génériques seront progressivement intégrées au Domain Core.

Les règles spécifiques resteront dans leurs Vertical Modules respectifs.

Cette séparation permet d'enrichir continuellement le Core sans introduire de dépendances métier.