Refactoring Product Models¶

Statut¶

Phase de refactorisation applicative clôturée à la frontière 106.

Cette page décrit l'état stabilisé du chantier product-models et son point d'arrêt architectural. Elle ne constitue plus une liste de découpages à poursuivre mécaniquement.

Objectif¶

Réduire les responsabilités historiques concentrées dans les fichiers product-models.php en introduisant des frontières explicites, testées et compatibles avec le runtime WordPress existant.

Le principe retenu est le suivant :

préserver les fonctions publiques ccx_product_models_* comme surface de compatibilité ;
déplacer les responsabilités stables vers src/Application/Catalog/ ;
conserver des wrappers minces dans plugins/ccx-feeds-industrial/includes/application/ ;
charger ces wrappers depuis le bootstrap applicatif ;
caractériser chaque frontière avant extraction ;
ne modifier ni les contrats frontend ni le comportement catalogue pendant l'extraction.

Structure cible obtenue¶

plugins/ccx-feeds-industrial/includes/
├── application/
│   ├── product-model-*.php          # wrappers de compatibilité
│   ├── product-models.php           # orchestration legacy résiduelle
│   └── product-model-enrichment.php
└── bootstrap/
    └── product-models-application.php

src/Application/Catalog/
├── CatalogRowProjector.php
├── PcStorageTypeConditionBuilder.php
├── PcStorageTypeLabelMap.php
├── PcStorageTypeOptionsBuilder.php
└── ...                              # owners applicatifs déjà extraits

tests/
├── Application/Catalog/             # tests des owners applicatifs
└── Runtime/                         # caractérisation des frontières runtime

La liste complète des responsabilités reste décrite dans Cartographie Product Models.

Modèle de frontière¶

Une responsabilité extraite suit normalement ce chemin :

appel historique / frontend
        ↓
fonction ccx_product_models_*()
        ↓
wrapper application/product-model-*.php
        ↓
owner src/Application/Catalog/*
        ↓
adaptateurs runtime nécessaires

Le wrapper protège la compatibilité WordPress. L'owner applicatif porte la logique testable. Le bootstrap rend la frontière disponible sans imposer au frontend la connaissance des classes internes.

Dernières frontières clôturées¶

Frontière 103 — PC Storage Type Labels¶

La table de labels des types de stockage PC est portée par un owner applicatif et exposée par un wrapper de compatibilité.

Frontière 104 — PC Storage Type Condition¶

La construction des conditions de type de stockage PC est portée par PcStorageTypeConditionBuilder et chargée par le bootstrap applicatif.

Frontière 105 — PC Storage Type Options¶

La construction des options et des compteurs de stockage PC est portée par PcStorageTypeOptionsBuilder. Le wrapper conserve la résolution de verticale et l'accès au catalogue historique.

Frontière 106 — Catalog Row Projection¶

La projection des lignes catalogue est portée par CatalogRowProjector, avec conservation des règles historiques de série, famille, modèle, normalisation iPhone Air et stockage des variantes.

Le wrapper product-model-catalog-row-projection.php maintient la surface procédurale attendue par le plugin.

État de validation à la clôture¶

La clôture de la frontière 106 a été validée avec :

Validation	Résultat
Application	363 tests, 2 228 assertions
Runtime	975 tests, 17 159 assertions
Suite standard complète	1 502 tests, 19 679 assertions
`git diff --check`	propre
Working tree	propre
`TODO / FIXME / HACK` dans le périmètre audité	aucun
wrappers `product-model-*` détectés	93
fonctions historiques encore détectées dans `application/product-models.php`	78

Commit de référence de clôture : 7f1b39cc (refactor: load catalog row projection wrapper).

Point d'arrêt architectural¶

Le nombre de fonctions restant dans application/product-models.php n'est pas une cible de réduction en soi.

La phase est arrêtée ici parce que :

les responsabilités stables identifiées ont désormais des frontières explicites ;
les extractions récentes sont protégées par des tests de caractérisation ;
la suite complète est verte ;
poursuivre uniquement pour réduire la taille du fichier augmenterait le risque sans bénéfice architectural démontré.

Toute extraction supplémentaire doit donc partir d'une responsabilité prouvée, d'un besoin produit ou d'une dette clairement qualifiée. Elle ne doit pas être déclenchée par un objectif arbitraire de nombre de lignes ou de fonctions.

Invariants de maintenance¶

Toute évolution future de cette zone doit préserver les règles suivantes :

caractériser le comportement avant extraction ;
conserver les signatures publiques pendant la transition ;
maintenir les wrappers comme frontières de compatibilité tant que leurs consommateurs existent ;
placer la logique métier/applicative testable dans src/Application/Catalog/ ;
ne pas introduire de dépendance WordPress dans les owners applicatifs ;
mettre à jour les inventaires de références lorsque l'ajout d'un wrapper crée volontairement un nouveau consommateur ;
exécuter les tests ciblés, Application, Runtime puis la suite complète avant fermeture d'une nouvelle frontière ;
maintenir git diff --check et le working tree propres à la certification.

Ce qui reste legacy¶

plugins/ccx-feeds-industrial/includes/application/product-models.php reste une surface historique contenant de l'orchestration et des responsabilités qui ne justifient pas encore une extraction autonome.

legacy signifie ici compatibilité conservée, pas code à supprimer immédiatement.

Aucune nouvelle extraction ne doit être réalisée sans :

responsabilité claire ;
test de caractérisation ;
owner cible identifié ;
bénéfice architectural ou produit explicite.