Aller au contenu

CMonChoix Platform — Master Plan

Status: HISTORICAL SNAPSHOT / GOVERNANCE REFERENCE

Ce document conserve un ancien plan directeur d'industrialisation de CMonChoix Platform.

Il reste utile pour comprendre certaines décisions, noms de chantiers et intentions qui ont structuré le dépôt, mais il ne décrit pas l'état CURRENT et ne doit pas être utilisé comme backlog opérationnel sans revalidation.

Les chemins, épics, seuils ou composants mentionnés dans l'ancien plan peuvent avoir été renommés, déplacés, réalisés autrement ou abandonnés.

Ce qui reste valable

Plusieurs principes du plan restent cohérents avec la gouvernance actuelle :

  1. une responsabilité claire par composant ;
  2. le Runtime orchestre sans porter la logique métier ;
  3. les spécificités métier restent isolées ;
  4. les performances sont mesurées avant optimisation ;
  5. documentation, tests et audits font partie du livrable ;
  6. les refactorings doivent rester petits, vérifiables et réversibles.

Ces principes doivent toutefois être lus avec les documents CURRENT de l'architecture, des Contracts et de la Definition of Done.

Ancienne cible d'architecture

Le plan proposait notamment une organisation de type :

Platform
├── application
├── domain
├── infrastructure
├── pipeline
├── mapping
├── runtime
├── frontend
├── admin
├── tests
├── tools
└── docs

Cette arborescence est HISTORICAL. Elle ne doit pas être recréée mécaniquement si le dépôt courant utilise d'autres frontières ou emplacements.

La source de vérité pour le code CURRENT reste le dépôt réellement chargé et testé.

Anciennes épics

Le plan historique suivait des chantiers tels que :

  • Pipeline v2 ;
  • Mapping v2 ;
  • Category Engine ;
  • Merchant Engine ;
  • Runtime v2 ;
  • Engineering Tooling ;
  • Architecture Audit v2.

Ces noms expliquent encore certains fichiers ou commentaires, mais leur présence ne prouve pas qu'un chantier soit encore ouvert, incomplet ou prioritaire.

Avant de reprendre un ancien epic :

  1. vérifier le comportement CURRENT ;
  2. identifier la source d'autorité actuelle ;
  3. rechercher les remplacements déjà introduits ;
  4. confirmer que le problème initial existe encore ;
  5. reformuler le besoin dans l'architecture actuelle.

Anciennes conventions de catégories et marchands

Le plan proposait des dossiers categories/ et merchants/ comme organisation cible.

Cette convention ne constitue plus à elle seule un contrat d'architecture.

Aujourd'hui, les responsabilités doivent être raisonnées par couche :

  • logique générique dans le Domain Core ou les Contracts appropriés ;
  • logique propre à une famille produit dans les Vertical Modules ;
  • logique propre à une source/marchand dans les feeds ou adapters concernés ;
  • orchestration dans le Runtime ;
  • mutations via des Write Services explicites.

Ajouter un marchand n'implique pas de créer une nouvelle verticale, et ajouter une verticale n'active aucun feed.

Contraintes VPS : principes encore utiles

Les contraintes suivantes restent de bons garde-fous lorsqu'elles sont applicables :

  • éviter les chargements mémoire non bornés ;
  • borner les traitements de gros volumes ;
  • mesurer durée et mémoire sur les traitements importants ;
  • préférer des accès ciblés aux boucles massives lorsque cela améliore réellement le comportement ;
  • documenter les index ou préconditions critiques.

Elles ne remplacent pas une mesure ou un diagnostic actuel.

Seuils et métriques historiques

Des seuils tels que « aucun nouveau fichier métier au-delà de 20 Kio » faisaient partie de l'ancien cadre de travail.

Ils sont HISTORICAL et ne constituent pas des quality gates CURRENT sauf s'ils sont réintroduits explicitement dans la CI, la Definition of Done ou un ADR actuel.

De même, les anciennes mentions génériques d'« audits verts » doivent être remplacées par les commandes réellement disponibles pour le périmètre concerné, par exemple make check, make doctor, make guard-static, make guard-runtime ou les tests spécifiques documentés.

Comment utiliser ce document aujourd'hui

Utiliser ce Master Plan pour :

  • comprendre l'origine d'un ancien nom de chantier ;
  • retrouver l'intention derrière une extraction historique ;
  • comparer une ancienne cible avec le dépôt actuel ;
  • éviter de répéter une dette déjà identifiée.

Ne pas l'utiliser pour :

  • décider qu'un fichier doit être déplacé parce qu'il n'est pas dans l'ancienne arborescence ;
  • supposer qu'un epic est encore ouvert ;
  • supprimer un composant qualifié jadis de legacy ;
  • introduire une règle métier dans une mauvaise couche ;
  • considérer une ancienne métrique comme gate CURRENT.

Références CURRENT

Pour une évolution nouvelle, commencer plutôt par :