Contrat global de cohérence¶

Statut¶

Spécification de cohérence du cœur de plateforme (M3).

À quoi sert cette page ?¶

Cette page définit comment les différentes parties de CMonChoix restent cohérentes lorsqu'une vérité métier évolue.

Le point essentiel à comprendre est qu'il existe deux niveaux de cohérence :

cohérence forte dans un même agrégat : les règles internes d'un Product doivent rester vraies immédiatement ;
cohérence éventuelle entre domaines : une projection ou le catalogue peut avoir un léger retard avant de refléter une nouvelle vérité Product.

Un retard temporaire est donc acceptable. Une divergence silencieuse et permanente ne l'est pas.

Vue générale¶

Product Domain — source de vérité
        ↓
Événements
        ↓
Runtime Sync Layer
        ↓
Event Store
        ↓
Replay Engine
        ↓
Projection Engine
        ↓
Catalog Domain — vue dérivée

1. Cohérence forte dans l'agrégat Product¶

À l'intérieur d'un seul Product :

l'identité doit rester cohérente ;
les invariants doivent toujours être respectés ;
les conflits doivent être explicites ;
une opération ne doit pas laisser un Product dans un état partiellement valide.

Il n'y a pas de « on corrigera plus tard » à l'intérieur de cette frontière métier.

2. Cohérence éventuelle entre domaines¶

Entre Product, projections et Catalog, la propagation peut être légèrement différée.

Exemple :

l'identité d'un Product est validée ;
l'événement correspondant est émis ;
le Runtime le traite quelques instants plus tard ;
la projection est reconstruite ;
le Catalog reflète enfin la nouvelle information.

Pendant ce court intervalle, le Product peut être correct alors que la vue catalogue est encore ancienne.

Les règles à ne pas casser¶

Product reste la source de vérité¶

Les autres couches sont dérivées. Une projection ou une vue catalogue ne doit pas réécrire la vérité Product simplement parce qu'elle est différente.

Une divergence doit être détectable¶

Si Product et Catalog ne correspondent plus, l'écart doit pouvoir être observé, mesuré et diagnostiqué.

La convergence doit être idempotente¶

Rejouer une réconciliation avec les mêmes entrées doit aboutir au même état sans créer de doublons ou d'effets supplémentaires.

Le replay doit rester sûr¶

Le système doit pouvoir reconstruire un état dérivé à partir de l'historique prévu par l'architecture sans corrompre la source.

Pas de mutation transversale sauvage¶

Catalog, Projection et Runtime ne doivent jamais modifier directement le Product Domain.

Comment traiter une incohérence¶

Lorsqu'une divergence apparaît :

Détecter
   ↓
Classifier
   ↓
Comprendre si elle est temporaire ou structurelle
   ↓
Choisir l'action adaptée

Trois grandes situations sont possibles :

retard transitoire → attendre ou relancer le traitement prévu ;
projection incorrecte → reconstruire la projection ;
problème de vérité Product → corriger le domaine Product par sa frontière officielle.

On ne doit pas traiter les trois cas de la même manière.

Ce que le système accepte¶

Sont acceptables :

une projection momentanément en retard ;
un catalogue temporairement ancien ;
un traitement d'événement qui échoue puis réussit après retry.

Ne sont pas acceptables :

corruption silencieuse ;
divergence impossible à détecter ;
état incohérent irréversible ;
correction manuelle d'une vue dérivée prise ensuite pour nouvelle vérité.

Modèle temporel¶

La plateforme ne suppose pas :

une horloge globale parfaitement synchronisée ;
un ordre absolu de tous les événements ;
une propagation instantanée.

Elle exige surtout un ordre cohérent dans le périmètre d'un même agrégat et des mécanismes de convergence fiables.

Ce que CMonChoix garantit¶

Le modèle vise à garantir :

la correction du Product Domain ;
l'immutabilité des événements lorsqu'ils sont utilisés comme historique ;
la capacité de replay prévue ;
des projections déterministes.

Il ne promet pas :

un catalogue toujours mis à jour instantanément ;
un ordre global unique entre tous les événements ;
zéro délai de propagation.

Reprise après incohérence¶

La stratégie générale est :

identifier la source de vérité concernée ;
vérifier l'historique ou les événements utiles ;
rejouer seulement le périmètre nécessaire lorsque le mécanisme est disponible et certifié ;
reconstruire les projections dérivées ;
resynchroniser le catalogue ;
comparer avant/après et vérifier l'absence de nouvelle divergence.

Pour un nouveau mainteneur¶

Si tu constates « le Product est correct mais la page affiche encore l'ancienne donnée », ne change pas directement la page.

Vérifie plutôt :

la projection est-elle à jour ?
l'événement ou le run responsable a-t-il été traité ?
existe-t-il une erreur Runtime ?
une reconstruction officielle remet-elle les couches en cohérence ?

Le bon réflexe est de faire converger les couches dérivées vers la source, jamais l'inverse.

Décision¶

Statut historique de la spécification : IMPROVE.

Cette page décrit l'autorité de cohérence visée par cette architecture. Lors d'une intervention réelle, vérifier également l'état Runtime courant et les capacités effectivement câblées avant de supposer qu'un mécanisme cible est déjà actif.