Classification des composants¶

Status: GOVERNANCE / GUIDE DE MIGRATION

Cette page fournit une méthode pour décider quoi faire d’un composant existant lors d’une évolution d’architecture.

Elle ne décrit pas un état Runtime et ne constitue pas une liste de composants déjà classifiés.

L’objectif n’est pas de conserver ou supprimer du code selon son âge. L’objectif est de préserver la valeur métier et opérationnelle tout en respectant les frontières actuelles de la Platform.

Pourquoi classifier¶

Avant de déplacer, réécrire ou supprimer un composant, il faut distinguer :

la responsabilité qu’il porte réellement ;
les consommateurs qui l’appellent encore ;
la valeur métier qu’il contient ;
les dépendances techniques qu’il impose ;
son niveau de preuve actuel ;
la frontière cible dans laquelle cette responsabilité devrait vivre.

Un fichier peut contenir plusieurs responsabilités et donc plusieurs classifications différentes.

Les classifications utiles¶

KEEP¶

Le composant reste à sa place actuelle.

Cette décision est adaptée lorsque :

sa responsabilité est claire ;
sa couche est correcte ;
ses dépendances respectent l’architecture ;
son comportement est suffisamment couvert par des tests ou audits ;
le déplacer n’apporterait pas de bénéfice réel.

KEEP ne signifie pas « parfait ». Il signifie que la migration de ce composant n’est pas justifiée.

MIGRATE¶

La responsabilité reste utile, mais doit être déplacée vers une frontière plus appropriée.

Exemples :

logique métier retirée d’un Adapter pour rejoindre une couche applicative ou verticale ;
lecture SQL encapsulée derrière un Reader ;
mutation dispersée déplacée vers un Write Service ;
compatibilité Frontend isolée dans un Adapter.

Avant migration, le comportement actuel doit être caractérisé.

REWRITE¶

La responsabilité est toujours nécessaire, mais l’implémentation actuelle est trop couplée ou trop ambiguë pour être déplacée proprement.

Une réécriture est justifiée lorsque :

plusieurs responsabilités sont mélangées ;
les dépendances sont circulaires ou implicites ;
les effets de bord empêchent une extraction sûre ;
le comportement peut être décrit et testé indépendamment de l’ancien code.

Une réécriture ne doit pas être une occasion de réinventer le contrat métier sans preuve.

COMPATIBILITY¶

Le composant est conservé temporairement pour préserver un consommateur historique pendant qu’une frontière canonique est mise en place.

Exemples :

wrapper de namespace ;
conversion DTO → tableau legacy dans un Adapter ;
façade historique vers un nouveau service ;
ancien point d’entrée maintenu pendant une migration progressive.

Une compatibilité doit être :

explicitement identifiée ;
bornée à un rôle précis ;
observée et testée ;
supprimée seulement lorsque ses consommateurs ont disparu.

HISTORICAL¶

Le composant, document ou script n’appartient plus au chemin CURRENT mais reste utile pour comprendre une ancienne décision, un audit ou une migration.

Il ne doit pas être utilisé comme preuve de l’état actuel sans revalidation.

DELETE¶

La suppression n’est justifiée que lorsque les preuves montrent que la responsabilité n’est plus nécessaire ou qu’elle est entièrement remplacée.

Avant suppression, vérifier :

références dans le dépôt ;
chargement par bootstrap ;
appels Runtime ;
bind mounts et déploiement ;
tests ou outils qui chargent directement le fichier ;
mécanisme de rollback si le composant est critique.

Un fichier ancien n’est jamais supprimé uniquement parce qu’il semble inutilisé.

Classifier une responsabilité, pas seulement un fichier¶

Un même fichier historique peut contenir :

orchestration           → KEEP ou MIGRATE
règle métier locale     → MIGRATE vers Vertical Module
lecture SQL             → MIGRATE derrière Reader
mutation persistante    → MIGRATE vers Write Service
shim historique         → COMPATIBILITY
patch devenu inutile    → DELETE

La classification doit donc être faite au niveau où la responsabilité est réellement identifiable.

Questions à poser avant décision¶

Qui appelle ce composant aujourd’hui ?
Est-il chargé dans le Runtime concerné ?
Quelle décision possède-t-il réellement ?
Cette décision appartient-elle à sa couche actuelle ?
Existe-t-il déjà une source canonique concurrente ?
Peut-on caractériser son comportement avant modification ?
La migration simplifie-t-elle réellement les dépendances ?
Une compatibilité temporaire est-elle nécessaire ?
Quelle preuve permettra de supprimer l’ancienne implémentation ?

Cas particuliers¶

Read / Write¶

Un composant qui mélange observation et mutation doit être découpé selon les effets réels, pas selon son nom.

La cible reste :

Read Service / Reader
        ↓
observation

Write Service
        ↓
mutation explicite

Verticales¶

Une règle spécifique à une famille produit reste dans un Vertical Module tant qu’elle n’est pas prouvée générique sur plusieurs domaines.

Frontend¶

Le Frontend et les Adapters ne deviennent pas propriétaires de la vérité métier. Une logique de résolution trouvée dans un template ou un wrapper doit être considérée comme candidate à migration.

Projections¶

Une projection étant dérivée et reconstructible, sa persistance ne lui donne pas autorité métier. Une règle présente uniquement dans la génération ou le rendu d’une projection doit être examinée avec prudence avant extraction.

Preuves attendues¶

Une classification importante devrait citer, selon le risque :

chemins et points d’entrée ;
appels ou références ;
tests de caractérisation ;
audits read-only ;
métriques avant/après ;
impact sur les statuts resolved, unknown, ambiguous, conflict ;
procédure de rollback ou de restauration.

Invariants¶

L’âge du code ne détermine pas sa valeur.
La présence dans Git ne prouve pas l’usage Runtime.
Une migration déplace une responsabilité, pas seulement un fichier.
Une compatibilité temporaire n’est pas une nouvelle source de vérité.
Aucun composant critique n’est supprimé sans preuve de remplacement ou d’inutilité.
Les frontières CURRENT priment sur les anciens plans de migration.