Database Schema Evolution¶
L'évolution du schéma de données est une opération structurante pour CMonChoix Platform.
Contrairement aux évolutions fonctionnelles, une modification du schéma impacte potentiellement plusieurs couches de la Platform :
- Pipeline
- Domain Core
- Write Services
- Runtime
- Frontend
- Outils d'exploitation
Chaque évolution doit donc être conçue pour préserver la stabilité de la Platform tout en permettant son enrichissement progressif.
Objectifs¶
La stratégie d'évolution du schéma poursuit plusieurs objectifs :
- garantir la compatibilité des traitements ;
- préserver les données existantes ;
- limiter les interruptions de service ;
- permettre une migration progressive ;
- conserver une architecture lisible.
Principes¶
Les évolutions suivent plusieurs principes fondamentaux.
Compatibilité ascendante¶
Une évolution du schéma doit, autant que possible, rester compatible avec les traitements existants.
Lorsque ce n'est pas possible, une phase de transition est privilégiée.
Évolution incrémentale¶
Les modifications importantes sont découpées en plusieurs étapes.
Par exemple :
Ajout d'une structure
↓
Migration progressive
↓
Validation
↓
Suppression de l'ancien modèle
Cette approche réduit les risques de régression.
Séparation des migrations¶
Les migrations de structure sont indépendantes :
- des migrations métier ;
- des reconstructions de projections ;
- des optimisations.
Chaque évolution poursuit un objectif unique.
Types d'évolution¶
Plusieurs catégories de modifications peuvent être rencontrées.
Création¶
Ajout d'une nouvelle structure destinée à accueillir un nouveau concept.
Cette opération est la moins risquée lorsqu'elle n'impacte aucun consommateur existant.
Extension¶
Ajout de nouvelles informations dans une structure existante.
Cette évolution doit préserver le comportement des traitements existants.
Remplacement¶
Lorsqu'une structure devient insuffisante, une nouvelle structure peut être créée.
Le remplacement suit généralement le cycle suivant :
Nouvelle structure
↓
Double alimentation
↓
Migration
↓
Validation
↓
Suppression de l'ancienne
Suppression¶
Une structure ne peut être supprimée qu'après :
- migration complète ;
- validation des consommateurs ;
- suppression des dépendances ;
- mise à jour de la documentation.
Reconstruction¶
Une évolution du schéma peut nécessiter la reconstruction de certaines données.
Les reconstructions concernent principalement :
- les projections ;
- les caches ;
- les représentations de navigation.
Les données sources restent inchangées.
Validation¶
Une évolution est validée lorsque :
- les traitements fonctionnent correctement ;
- les projections sont cohérentes ;
- les consommateurs restent compatibles ;
- les performances restent conformes ;
- les audits ne détectent aucune régression.
Invariants¶
Les évolutions du schéma doivent toujours respecter plusieurs invariants.
Les responsabilités restent identiques¶
Une table ne change jamais de mission.
Si une nouvelle responsabilité apparaît, une nouvelle structure est créée.
Les traitements restent reproductibles¶
Une migration ne doit jamais empêcher la reconstruction des données.
Les projections restent dérivées¶
Les structures de lecture ne deviennent jamais une nouvelle source de vérité.
Les consommateurs restent découplés¶
Le Runtime et le Frontend continuent d'utiliser les contrats prévus par l'architecture.
Anti-patterns¶
Les situations suivantes doivent être évitées.
Modifier directement une structure critique¶
Une évolution importante passe par une phase de transition.
Mélanger migration et logique métier¶
Une migration adapte les structures.
Les traitements métier restent indépendants.
Supprimer prématurément une structure¶
Une structure ne disparaît qu'après validation complète de son remplacement.
Utiliser une migration pour corriger des données¶
Les corrections métier doivent être réalisées par les traitements officiels.
Documentation¶
Toute évolution importante du schéma doit être accompagnée :
- d'une mise à jour de la documentation Database ;
- d'une mise à jour des références techniques ;
- d'une mise à jour des ADR si nécessaire ;
- d'une description des impacts sur les consommateurs.
La documentation fait partie intégrante de l'évolution.
Vision long terme¶
Le schéma de données de CMonChoix Platform est appelé à évoluer pendant de nombreuses années.
Cette évolution doit rester :
- progressive ;
- documentée ;
- reproductible ;
- compatible avec les principes de l'architecture Identifier First.
Une évolution réussie est une évolution qui améliore la Platform sans remettre en cause les contrats fondamentaux entre ses différentes couches.