Domaine Catalog — comprendre le catalogue visible par l'utilisateur¶

Statut¶

Document de référence pour la transmission du projet.

À quoi sert le domaine Catalog ?¶

Le domaine Catalog organise la manière dont les produits sont présentés et découverts sur CMonChoix.

Il se situe après le domaine Product : il ne décide pas ce qu'est réellement un produit, mais transforme la vérité produit en structures pratiques pour la navigation, les catégories, les filtres et les listes visibles par l'utilisateur.

La distinction la plus importante est donc :

Product Domain = vérité métier sur le produit
        ↓
Catalog Domain = organisation de cette vérité pour la consultation
        ↓
Frontend = affichage au visiteur

Exemple simple¶

Imaginons qu'un smartphone Samsung soit correctement identifié dans le Product Domain.

Le Catalog peut ensuite décider de le faire apparaître dans une structure de lecture telle que :

Smartphones & Objets connectés
└── Smartphones
    └── [produit projeté]

Le Catalog peut aussi fournir les informations nécessaires aux filtres : marque, capacité, gamme ou autres attributs autorisés.

Mais il ne doit pas changer l'identité du produit pour le faire entrer dans une catégorie.

Pourquoi séparer Product et Catalog ?¶

Sans cette séparation, une règle d'affichage pourrait finir par modifier la vérité métier.

Par exemple, une erreur de navigation ne doit pas conduire à changer artificiellement l'identité canonique d'un produit. Il faut corriger la projection, le routage ou la donnée responsable au bon niveau.

La séparation permet aussi de reconstruire le catalogue lorsque les règles de navigation évoluent sans recréer toute la vérité produit.

Responsabilités du Catalog¶

Le domaine Catalog est responsable notamment de :

structures de découverte des produits ;
vues de navigation ;
regroupements destinés à la consultation ;
facettes et filtres ;
collections de produits ;
représentations de produits adaptées à la lecture ;
structures reconstruisibles utilisées par le frontend.

Ce qu'il ne doit jamais décider¶

Le Catalog ne doit pas :

définir l'identité canonique d'un produit ;
résoudre les identifiants marchands ;
arbitrer les conflits du Product Domain ;
devenir la source de vérité du prix ou du stock ;
contenir une règle propre à un marchand simplement pour obtenir le bon affichage ;
modifier directement l'état métier d'un Product.

Les principaux concepts¶

CatalogItem¶

Un CatalogItem est une représentation d'un Product adaptée au catalogue.

Ce n'est pas un deuxième Product. Si le Catalog est supprimé puis reconstruit, le Product doit continuer d'exister dans sa source autoritative.

CatalogView¶

Une CatalogView décrit une vue destinée à l'utilisateur : par exemple une page, un ensemble de produits ou une organisation particulière du catalogue.

CatalogCollection¶

Une CatalogCollection regroupe des produits selon une règle de lecture. Elle peut être dynamique et reconstruite lorsque les données changent.

Un CatalogFilter représente une contrainte de recherche ou de navigation. Il aide à sélectionner les éléments affichés ; il ne redéfinit pas leur identité.

Les deux composants à connaître¶

Moteur de projection catalogue¶

Le Catalog Projection Engine transforme les données autoritatives en représentations destinées au catalogue.

→ Comprendre le moteur de projection

Couche de synchronisation runtime¶

La Runtime Synchronization Layer coordonne la propagation des changements du Product Domain vers les projections du Catalog.

→ Comprendre la synchronisation runtime

Cycle de vie simplifié¶

1. Un Product est créé ou modifié
              ↓
2. Le changement doit être propagé
              ↓
3. Le moteur de projection calcule la représentation Catalog
              ↓
4. Les structures de lecture sont mises à jour
              ↓
5. Le frontend lit ces structures

Le catalogue peut être temporairement en retard sur la vérité produit. C'est le principe de cohérence éventuelle : la vérité reste correcte, puis les représentations dérivées convergent vers elle.

Invariants à retenir¶

Le Catalog dérive de sources autoritatives.
Il ne remplace jamais le Product Domain comme source de vérité.
Ses projections doivent pouvoir être reconstruites.
Une reconstruction complète et une mise à jour incrémentale doivent converger vers le même résultat pour les mêmes données et règles.
Une anomalie d'affichage ne justifie pas une modification arbitraire du Product.

Comment diagnostiquer un problème de catalogue¶

Si un produit est absent, mal classé ou mal présenté, ne commence pas par modifier directement la base de données.

Utilise plutôt cette chaîne :

Le Product existe-t-il et son identité est-elle correcte ?
        ↓ oui
La donnée nécessaire à la projection est-elle correcte ?
        ↓ oui
La projection Catalog a-t-elle été reconstruite / synchronisée ?
        ↓ oui
Le routage ou la structure de navigation est-il correct ?
        ↓ oui
Le frontend lit-il la bonne projection ?

Cette méthode permet de déterminer si le problème appartient au Product Domain, au moteur de projection, à la synchronisation, à la navigation ou au frontend.

Pour la reprise du projet¶

Quand tu vois un terme comme CatalogItem, CatalogView ou CatalogCollection, pense copie de lecture reconstruisible, pas vérité métier indépendante.

Quand tu vois une catégorie incorrecte sur le site, ne suppose pas que la table ou la page affichée est la source de vérité. Remonte toujours vers la projection puis vers sa source.