Cycle de vie des données¶

Status: CONTRACT

Rôle¶

Cette page explique comment une donnée traverse CMonChoix Platform depuis sa réception jusqu'à sa consommation, sans mélanger les responsabilités de chaque étape.

Le cycle de vie n'est pas une simple suite de tables. Il décrit une progression logique : acquisition, préparation, décision métier, projection, persistance, lecture.

Vue d'ensemble¶

Feed marchand
      ↓
Réception / import
      ↓
Stage
      ↓
Normalisation
      ↓
Enrichissement
      ↓
Domain Core + Vertical Modules
      ↓
Résolution / Canonical Identity
      ↓
Projection Builder
      ↓
Write Service
      ↓
Persistance
      ↓
Read Services / Frontend / Runtime adapters

Selon le composant, certaines étapes peuvent être matérialisées différemment. Le principe important est la séparation des responsabilités, pas l'existence obligatoire d'une table pour chaque case.

1. Réception¶

Les données proviennent d'une source marchande externe.

À ce stade :

elles décrivent ce que le marchand publie ;
aucune vérité métier CMonChoix n'est encore construite ;
les erreurs ou ambiguïtés de la source doivent rester traçables.

2. Import¶

L'import rend la source exploitable par le Pipeline tout en conservant son origine.

Les objectifs sont notamment :

traçabilité ;
reprise ;
audit ;
comparaison entre exécutions.

L'import ne doit pas fabriquer silencieusement une Canonical Identity.

3. Stage¶

Le Stage est une zone de travail proche de la source.

Il peut servir à :

préparer les traitements ;
auditer les données ;
comparer des runs ;
simuler des transformations.

Le Stage n'est pas une couche Frontend et n'est pas une vérité métier.

4. Normalisation¶

La normalisation harmonise les représentations techniques et syntaxiques pour rendre les données comparables.

Elle peut par exemple :

nettoyer des formats ;
normaliser des identifiants ;
uniformiser des valeurs ;
préparer les règles de résolution.

Elle ne doit pas confondre harmonisation et décision métier.

5. Enrichissement¶

L'enrichissement ajoute des informations calculées ou dérivées utiles aux étapes suivantes.

Les enrichissements génériques restent dans les couches génériques ; les règles spécifiques à une famille de produits appartiennent aux Vertical Modules.

6. Résolution et Canonical Identity¶

Le Resolver examine les preuves disponibles et produit un résultat explicite.

Les statuts canoniques doivent rester distincts :

resolved ;
unknown ;
ambiguous ;
conflict.

Le cycle de vie ne garantit pas qu'une donnée devienne forcément resolved. Une absence de preuve suffisante peut conduire légitimement à unknown, et un conflit réel doit rester visible.

7. Projection¶

Le Projection Builder transforme l'état amont validé en Read Model déterministe.

Il décide de la forme projetée mais n'écrit pas directement dans la persistance.

Une projection :

est dérivée ;
est optimisée pour la lecture ;
reste reconstruisible ;
ne devient pas une nouvelle vérité métier.

8. Persistance par Write Service¶

La mutation durable appartient à un Write Service ou à un mécanisme technique explicitement identifié.

Le Write Service applique une décision ou un résultat déjà produit. Il ne doit pas inventer une règle métier au moment de l'écriture.

Pour une reconstruction importante :

Builder
→ résultat en mémoire
→ Write Service
→ compteurs d'exécution
→ audit de validation

9. Lecture¶

Les consommateurs lisent des projections ou des contrats de lecture adaptés à leur besoin.

Le Frontend ne doit pas recalculer :

l'identité ;
les conflits ;
le meilleur candidat ;
les règles de projection.

Les Read Services observent et analysent sans écrire.

États techniques et états métier¶

Ne pas confondre :

l'état d'un run ou d'un batch ;
l'état d'une ligne intermédiaire ;
le statut de résolution métier ;
l'état d'une projection ;
l'état d'un cache ou d'un lock.

Deux valeurs appelées status peuvent avoir des significations complètement différentes selon la couche.

Avant tout diagnostic, identifier le contrat du statut observé.

Reconstruction¶

Une reconstruction n'est pas un retour en arrière dans le cycle de vie.

Elle consiste à repartir d'un état amont fiable pour recalculer un état dérivé.

Exemples :

reconstruire une projection après évolution de code ;
régénérer une navigation ;
reconstruire un cache ;
recalculer une famille Product Models.

Pour la famille Product Models documentée actuellement :

Product Models
→ Variants
→ Specifications
→ Gallery

La disponibilité concrète des services et commandes doit être vérifiée avant exécution.

Données historiques altérées¶

Lorsqu'un ancien comportement a déjà muté destructivement un état dérivé, cet état ne doit pas servir de baseline.

La démarche correcte est :

retrouver l'état amont sain ;
reconstruire l'état dérivé ;
relancer l'audit ;
seulement ensuite comparer ou valider la nouvelle politique.

C'est particulièrement important pour les historiques Media Quality ayant pu altérer image_norm.

Reprise après interruption¶

Une interruption peut laisser :

un run incomplet ;
une projection partiellement reconstruite ;
un état technique de queue incohérent ;
des compteurs partiels.

Ne pas relancer aveuglément.

Avant reprise :

identifier le dernier état cohérent ;
vérifier l'idempotence du service concerné ;
vérifier le périmètre du rejeu ;
conserver les erreurs et skipped rows visibles ;
réauditer après reprise.

Ce qu'il ne faut pas faire¶

Ne jamais utiliser le cycle de vie comme justification pour :

écrire directement dans une projection ;
transformer un ambiguous en resolved par SQL ;
relire une projection comme source autoritaire du Pipeline ;
laisser le Frontend corriger une donnée manquante ;
lancer une mutation pendant un audit ;
supposer qu'un run plus récent est automatiquement plus fiable.

Tests attendus¶

Les transitions importantes doivent être testées pour :

déterminisme ;
traçabilité ;
reprise ;
idempotence des writes ;
absence d'écriture dans les lectures ;
conservation des statuts unknown, ambiguous, conflict ;
reconstruction d'états dérivés ;
comportement sur entrée partielle ou invalide.

Invariants¶

Chaque étape possède une responsabilité explicite.
La résolution peut légitimement rester incertaine.
Une projection est calculée avant d'être persistée.
La persistance ne fabrique pas la décision métier.
Les consommateurs lisent sans reconstruire l'amont.
Les états dérivés restent reconstruisibles.
Une reprise est bornée et vérifiée.
Une baseline historiquement altérée est régénérée avant comparaison.