Aller au contenu

Repository Cleanup Phase 1

Objectif

Stabiliser le repository CMonChoix Platform avant toute suppression, fusion ou migration de fichiers.

Cette phase ne modifie pas le code PHP. Elle fixe l'état de référence du repository et les règles de décision pour les nettoyages futurs.

Principes

  • Aucun fichier PHP n'est supprimé sans preuve d'inutilisation.
  • Aucun déplacement de classe n'est fait sans test vert.
  • Les changements doivent rester atomiques.
  • WordPress reste un runtime externe et ne doit jamais être versionné.
  • La documentation reste la source de vérité.

Namespace canonique actuel

Le namespace canonique actuellement chargé par Composer est :

CMonChoix\Platform\

Il pointe vers :

src/

Conséquence : les classes utilisées et testées aujourd'hui doivent être considérées comme canoniques lorsqu'elles utilisent :

CMonChoix\Platform\Domain\...
CMonChoix\Platform\Application\...
CMonChoix\Platform\Infrastructure\...

Namespace expérimental ou legacy

Les namespaces suivants sont considérés comme non canoniques tant que composer.json ne les charge pas explicitement :

CMonChoix\Domain\...
CMonChoix\Application\...
CMonChoix\Infrastructure\...

Ils peuvent contenir des prototypes utiles, mais ne doivent pas être utilisés comme référence principale sans migration contrôlée.

Domain Product : état Phase 1

Canonique actuel

Les fichiers suivants sont considérés comme la base Domain Product actuelle :

src/Domain/Product/Product.php
src/Domain/Product/ProductId.php
src/Domain/Product/ProductIdentifier.php
src/Domain/Product/IdentifierType.php

Raison : ils utilisent le namespace CMonChoix\Platform\Domain\Product et sont alignés avec l'autoload actuel.

Expérimental ou à classifier

Les fichiers suivants sont à conserver pour audit mais ne sont pas la référence actuelle :

src/Domain/Product/Aggregate/Product.php
src/Domain/Product/ValueObject/ProductId.php
src/Domain/Product/ValueObject/ProductIdentifier.php

Raison : ils utilisent le namespace CMonChoix\Domain\Product\..., hors autoload actuel.

Fichiers à corriger ou reclasser

Factory Domain incomplète

src/Domain/Product/Factory/ProductFactory.php

Statut : fichier suspect.

Problèmes observés :

  • pas d'ouverture <?php
  • pas de namespace
  • pas de imports

Action future : corriger, déplacer ou supprimer seulement après vérification des usages.

ProductDraft et factories mal placés

src/Application/Product/Draft/ProductDraft.php
src/Application/Product/Factory/ProductDraftFactory.php
src/Application/Product/Factory/ProductFactory.php

Statut : contenu probablement Domain, emplacement Application incorrect.

Raison : ces fichiers déclarent CMonChoix\Platform\Domain\Product alors qu'ils sont rangés sous src/Application.

Action future : migration contrôlée vers src/Domain/Product/... ou renommage namespace/dossier après tests.

Modules M12 à M34

Les dossiers suivants sont considérés comme modules expérimentaux ou jalons techniques :

src/Application/M12
src/Application/M17
src/Application/M19
src/Application/M20
src/Application/M21
src/Application/M22
src/Application/M24
src/Application/M25
src/Application/M26
src/Application/M27
src/Application/M28
src/Application/M29
src/Application/M30
src/Application/M31
src/Application/M32
src/Application/M33
src/Application/M34
src/Infrastructure/M13
src/Infrastructure/M14
src/Infrastructure/M15
src/Infrastructure/M16
src/Infrastructure/M18
src/Infrastructure/M23

Règle : ne pas les supprimer en bloc. Chaque module doit être classé comme :

  • à conserver ;
  • à fusionner ;
  • à migrer ;
  • à supprimer ;
  • à documenter comme prototype.

Doublons identifiés

Familles de doublons détectées :

EventBus.php
Product.php
ProductFactory.php
ProductId.php
ProductIdentifier.php
ProjectionEngine.php
ReplayEngine.php

Ces doublons ne sont pas forcément identiques. Ils représentent souvent des niveaux différents : Domain, Application, Infrastructure ou prototype de milestone.

docs-nginx

Le fichier suivant existe :

docs-nginx/default.conf

Statut Phase 1 : configuration officiellement branchée dans le service docs de docker-compose.yml.

Rôle : fournir une configuration versionnée et reproductible pour l'exposition statique de la documentation.

Décision : conserver docs-nginx comme configuration runtime dédiée à la documentation.

.gitignore

Statut : fonctionnel mais à nettoyer.

Points observés :

  • wordpress/ est ignoré plusieurs fois ;
  • les règles de runtime WordPress peuvent être simplifiées ;
  • site/, vendor/, secrets, dumps et backups sont correctement exclus.

Action future : patch dédié, sans toucher au code.

Ordre recommandé des prochains patches

  1. Nettoyer .gitignore sans changer son comportement.
  2. Ajouter cette page dans la navigation MkDocs.
  3. Créer une page Platform Core Contract V1.
  4. Corriger ou reclasser src/Domain/Product/Factory/ProductFactory.php.
  5. Déplacer proprement ProductDraft et ses factories si les tests restent verts.
  6. Classer les modules M12-M34 un par un.

Règles de validation

Pour tout patch PHP futur :

php -l <file>
composer test

Pour tout patch documentation :

mkdocs build

Décision Phase 1

La Phase 1 est une phase de stabilisation, pas de refactor massif.

Le repository doit d'abord devenir lisible et gouverné avant de devenir plus compact.