Resolver¶
Le Resolver est le moteur de décision du Domain Core.
Son rôle est d'évaluer les différents Candidates afin de produire une Canonical Identity unique, stable et explicable.
Toutes les verticales utilisent le même mécanisme de résolution. Seules les règles métier changent.
Sommaire¶
- Présentation
- Pourquoi un Resolver ?
- Responsabilités
- Cycle de résolution
- Les étapes
- Les conflits
- Les décisions
- Les invariants
- Les garde-fous
- Exemples
- Voir aussi
Présentation¶
Le Resolver est le cœur décisionnel de CMonChoix Platform.
Il reçoit un ou plusieurs Candidates.
Il compare leurs caractéristiques.
Il détermine :
- s'il existe une identité unique ;
- si plusieurs hypothèses restent possibles ;
- si un conflit doit être déclaré.
Le Resolver ne crée jamais de règle métier spécifique.
Il applique uniquement le mécanisme générique.
Pourquoi un Resolver ?¶
Plusieurs marchands peuvent décrire un même produit de façons très différentes.
Inversement, deux produits très proches peuvent sembler identiques.
Le Resolver garantit que :
- la décision reste cohérente ;
- les conflits sont détectés ;
- les décisions sont explicables ;
- toutes les verticales utilisent le même moteur.
Responsabilités¶
Le Resolver est responsable de :
- comparer les Candidates ;
- éliminer les hypothèses incompatibles ;
- détecter les conflits ;
- produire une Canonical Identity ;
- retourner un Resolution Status ;
- fournir les raisons de la décision.
Il n'est pas responsable :
- des règles Smartphone ;
- des règles Photo ;
- du Frontend ;
- des écritures SQL ;
- du Runtime.
Cycle de résolution¶
Identifiers
│
▼
Candidates
│
▼
Resolver
│
▼
Canonical Identity
│
▼
Projection
Les étapes¶
Le Resolver suit toujours le même processus.
1. Collecte¶
Tous les Candidates disponibles sont récupérés.
2. Comparaison¶
Les attributs communs sont comparés.
3. Détection des conflits¶
Les incompatibilités sont identifiées.
4. Évaluation¶
Les Candidates sont classés.
5. Décision¶
Le meilleur résultat est sélectionné.
6. Résolution¶
Une Canonical Identity est produite.
Les conflits¶
Le Resolver distingue plusieurs situations.
Aucun conflit¶
Une seule identité est possible.
Résultat :
resolved
Conflit faible¶
Plusieurs hypothèses restent plausibles.
Résultat :
resolved_candidate
Conflit fort¶
Les informations sont incompatibles.
Résultat :
conflict_blocking
Données insuffisantes¶
Aucune décision fiable n'est possible.
Résultat :
invalid
Les décisions¶
Le Resolver doit toujours produire une décision reproductible.
À données identiques :
→ même résultat.
La décision ne dépend jamais :
- du marchand ;
- du Frontend ;
- du Pipeline ;
- du Runtime.
Les invariants¶
Le Resolver :
- ne modifie jamais les données ;
- ne dépend jamais d'une verticale ;
- reste déterministe ;
- reste reproductible ;
- reste auditable.
Les garde-fous¶
Le Resolver ne doit jamais :
- masquer un conflit de marque ;
- masquer un conflit de famille produit ;
- créer une Canonical Identity artificielle ;
- contourner une Conflict Policy ;
- appliquer une règle métier spécifique.
Les Vertical Modules apportent leurs propres règles via les Contracts.
Exemple Smartphone¶
Candidates
Apple iPhone 16 Pro
Apple iPhone 16 Pro Max
↓
Conflict
↓
conflict_blocking
Le Resolver détecte le conflit.
La Policy Smartphone explique pourquoi.
Exemple Photo¶
Candidates
Canon EF-S 55-250 mm
Canon Zoom
↓
compatible enrichment
↓
resolved_candidate
La décision dépend de la Policy Photo.
Le Resolver reste identique.
Conclusion¶
Le Resolver constitue le moteur générique de résolution de CMonChoix Platform.
Sa stabilité est essentielle.
Les Vertical Modules ne remplacent jamais le Resolver.
Ils enrichissent uniquement les règles utilisées pendant la résolution.
Voir aussi¶
- Candidate
- Canonical Identity
- Projection
- Conflict Policy Contract
- Identity Resolver Contract