Cartographie Product Models¶
Statut¶
Cartographie de référence après clôture de la frontière 106.
Cette page décrit la répartition actuelle des responsabilités product-models entre le frontend, les wrappers de compatibilité, l'application historique et les owners de src/Application/Catalog/.
Vue d'ensemble¶
La zone product-models n'est plus considérée comme un monolithe à découper intégralement. Elle est organisée autour de frontières progressives :
Frontend WordPress
↓
fonctions publiques ccx_product_models_*
↓
wrappers includes/application/product-model-*.php
↓
owners src/Application/Catalog/*
Deux fichiers historiques restent volontairement structurants :
plugins/ccx-feeds-industrial/includes/frontend/product-models.php
plugins/ccx-feeds-industrial/includes/application/product-models.php
Ils assurent encore de l'orchestration et de la compatibilité. Leur seule taille ne constitue pas une dette suffisante pour déclencher une extraction.
Frontière frontend¶
Le frontend reste responsable de l'intégration WordPress et du rendu public :
- hooks et query vars ;
- résolution du contexte de requête ;
- SEO public ;
- rendu catalogue ;
- rendu fiche produit ;
- filtres et facettes visibles ;
- offres et marchands ;
- assemblage des assets frontend.
Les scripts interactifs majeurs déjà extraits restent séparés :
| Domaine | Wrapper PHP | Asset | État |
|---|---|---|---|
| Galerie produit | product-gallery-assets.php |
assets/product-gallery.js |
extrait et testé |
| Variantes produit | product-variants-assets.php |
assets/product-variants.js |
extrait et testé |
| Tiroir de filtres | catalog-filter-assets.php |
assets/catalog-filter-drawer.js |
extrait et testé |
| Auto-submit filtres | catalog-filter-assets.php |
assets/catalog-filter-autosubmit.js |
extrait et testé |
Frontière application WordPress¶
Le répertoire suivant constitue la couche de compatibilité procédurale :
plugins/ccx-feeds-industrial/includes/application/
Les fichiers product-model-*.php exposent les fonctions historiques ccx_product_models_* tout en déléguant progressivement la logique aux owners applicatifs.
À la certification de la frontière 106 :
- 93 wrappers/fonctions de frontière sont détectés dans les fichiers
product-model-*.php; - 78 fonctions historiques restent détectées dans
application/product-models.php.
Ces nombres sont des indicateurs d'inventaire, pas des objectifs de réduction.
Frontière Application Catalog¶
La logique extraite et testable est portée principalement par :
src/Application/Catalog/
Cette couche contient notamment des responsabilités dédiées pour :
- options de marque, série, modèle, réseau, stockage et spécifications ;
- normalisation de filtres ;
- facettes catalogue ;
- tri et pagination ;
- requêtes de variantes et d'offres ;
- identité et agrégation d'offres ;
- labels et couleurs ;
- disponibilité des variantes et spécifications ;
- projection de lignes catalogue ;
- règles de stockage PC.
Les classes de cette couche ne doivent pas dépendre directement de WordPress.
Frontières 103 à 106¶
| Frontière | Responsabilité | Owner applicatif | Wrapper |
|---|---|---|---|
| 103 | labels de type de stockage PC | PcStorageTypeLabelMap |
product-model-pc-storage-type-labels.php |
| 104 | condition SQL de type de stockage PC | PcStorageTypeConditionBuilder |
product-model-pc-storage-type-condition.php |
| 105 | options de type de stockage PC | PcStorageTypeOptionsBuilder |
product-model-pc-storage-type-options.php |
| 106 | projection des lignes catalogue | CatalogRowProjector |
product-model-catalog-row-projection.php |
Ces wrappers sont chargés depuis :
plugins/ccx-feeds-industrial/includes/bootstrap/product-models-application.php
Responsabilités historiques encore présentes¶
Frontend¶
Le fichier frontend/product-models.php conserve l'assemblage public et les responsabilités fortement liées à WordPress ou au rendu.
Les principaux groupes restent :
- SEO et routage ;
- filtres et facettes de rendu ;
- catalogue et pagination ;
- offres et marchands ;
- fiche produit et assemblage des blocs.
Ces groupes ne sont plus une roadmap automatique d'extraction. Une extraction future doit démontrer son intérêt avant modification.
Application¶
application/product-models.php conserve une partie de l'orchestration catalogue historique et des fonctions de compatibilité.
Le fichier doit être traité comme une surface legacy gouvernée :
- on peut y corriger un comportement ;
- on peut en extraire une responsabilité autonome ;
- on ne doit pas le découper uniquement pour réduire son volume.
Règle d'extraction future¶
Une nouvelle frontière n'est justifiée que si les quatre conditions suivantes sont réunies :
- une responsabilité durable est clairement identifiable ;
- son comportement actuel peut être caractérisé ;
- un owner cible cohérent existe dans l'architecture ;
- l'extraction apporte un bénéfice produit, de testabilité, de maintenabilité ou de frontière.
Le processus reste :
caractérisation
↓
owner applicatif
↓
wrapper de compatibilité
↓
bootstrap
↓
validation ciblée
↓
Application
↓
Runtime
↓
suite complète
Certification de référence¶
La frontière 106 a été clôturée sur le commit 7f1b39cc avec :
| Suite | Résultat |
|---|---|
| Application | 363 tests / 2 228 assertions |
| Runtime | 975 tests / 17 159 assertions |
| Full standard | 1 502 tests / 19 679 assertions |
git diff --check et le working tree étaient propres. Aucun TODO, FIXME ou HACK réel n'a été trouvé dans le périmètre final audité.
Décision¶
La refactorisation progressive est fermée à la frontière 106.
La prochaine évolution de product-models doit être traitée comme un nouveau besoin architectural, et non comme la continuation automatique de ce chantier.