Architecture Database¶

Status: CURRENT

Rôle¶

La couche Database conserve les différents états nécessaires au fonctionnement de CMonChoix Platform. Elle permet de stocker les données importées, les états intermédiaires du Pipeline, les résultats métier persistés, les projections de lecture et certains états techniques.

Elle ne décide pas de la vérité métier. Une valeur présente en base n'est fiable qu'en fonction de sa famille de données, de son origine et du composant qui l'a produite.

Vue d'ensemble¶

Le flux conceptuel est le suivant :

Sources marchandes
      ↓
Import / Stage
      ↓
Normalisation / enrichissement
      ↓
Domain Core + Vertical Modules
      ↓
Canonical Identity
      ↓
Projections
      ↓
Read Services / Runtime / Frontend

La base matérialise plusieurs de ces étapes, mais ne les fusionne pas.

Familles de données¶

Import et Stage¶

Ces données restent proches des sources marchandes et servent à :

tracer ce qui a été reçu ;
reproduire ou comparer une ingestion ;
diagnostiquer les problèmes en amont ;
alimenter les traitements suivants.

Elles ne sont pas destinées au Frontend et ne constituent pas une vérité métier consolidée.

États intermédiaires¶

Certains traitements persistent des données normalisées, enrichies ou préparatoires. Leur rôle est de rendre les traitements auditables et reprenables.

Ces structures peuvent contenir des informations utiles au Resolver ou à d'autres services, mais elles restent dépendantes de leur étape de production.

État métier persistant¶

Lorsqu'un résultat métier est persisté, sa signification provient du Domain Core et, lorsque nécessaire, d'un Vertical Module.

La base ne crée pas ce résultat ; elle le conserve.

Projections¶

Les projections sont des représentations dérivées et optimisées pour la lecture. Elles doivent être déterministes, reconstruisibles et indépendantes du rendu.

Une projection ne devient jamais la source de vérité métier simplement parce qu'elle est plus facile à interroger.

États techniques¶

Le Runtime et l'infrastructure peuvent aussi persister des informations telles que :

état d'un run ;
informations de reprise ;
locks ;
versions de schéma ;
caches techniques ;
métriques ou historiques d'exécution.

Ces données servent à l'exploitation. Elles ne doivent pas être interprétées comme des concepts métier.

Direction des dépendances¶

La direction logique doit rester descendante :

Source
  ↓
Stage
  ↓
Traitements
  ↓
Résultat métier
  ↓
Projection
  ↓
Lecture

Un consommateur en aval ne doit pas réécrire ou redéfinir silencieusement la signification d'une couche amont.

Ce que la Database ne doit pas faire¶

La couche Database ne doit pas :

décider qu'une identité est resolved, unknown, ambiguous ou conflict ;
contenir une règle métier spécifique à une verticale dans un trigger ou une requête ad hoc ;
devenir le lieu principal de calcul de la logique métier ;
être modifiée directement depuis un renderer Frontend ;
transformer une projection en source d'entrée du Domain Core ;
servir de raccourci pour contourner un Read Service ou un Write Service existant.

Préfixe SQL Runtime¶

Sur le Runtime actuellement documenté, le préfixe WordPress observé est :

wp_3888956

Ce préfixe appartient au contexte d'exploitation actuel. Il ne doit pas être codé en dur comme invariant global de l'architecture.

Avant toute commande SQL, vérifier le préfixe réellement actif dans l'environnement visé.

Observer avant d'écrire¶

Une investigation Database doit commencer en lecture seule.

Ordre recommandé :

identifier la famille de données concernée ;
trouver le composant qui écrit cette structure ;
vérifier le run, snapshot ou projection observé ;
comparer avec la source ou l'état amont pertinent ;
déterminer si le problème vient du calcul ou seulement de la persistance ;
utiliser un audit ou une simulation lorsque disponible ;
n'envisager une écriture qu'après identification du bon Write Service ou mécanisme de migration.

Questions de diagnostic¶

Quand une table semble incohérente, demander d'abord :

cette table est-elle source, intermédiaire, projection ou état technique ?
quelle version du code l'a produite ?
quel run ou batch est concerné ?
le problème existe-t-il déjà dans la couche amont ?
la table est-elle reconstruisible ?
un Read Service permet-il d'expliquer l'écart ?
un Write Service dédié existe-t-il pour la reconstruction ?

Pièges fréquents¶

Corriger directement une projection¶

Cela masque la cause et sera perdu au prochain rebuild.

Prendre une ligne SQL pour une preuve métier¶

Une ligne peut être périmée, intermédiaire, partielle ou issue d'un ancien run.

Corriger la base avant de comprendre le Pipeline¶

Un problème de normalisation ou de résolution réapparaîtra dès la prochaine ingestion.

Lire le Stage depuis le Frontend¶

Cela réintroduit le format marchand et contourne la frontière projection-first.

Confondre table technique et table métier¶

Un statut d'exécution, une option WordPress ou un lock n'a pas la même signification qu'une identité ou qu'une projection produit.

Évolution du schéma¶

Toute évolution structurelle doit préciser :

le statut CURRENT ou TARGET de la structure ;
le producteur et les consommateurs ;
la compatibilité ascendante nécessaire ;
le mécanisme de migration ;
le rollback ou la stratégie de récupération ;
les métriques permettant de valider la migration.

Une migration de schéma ne doit pas être déclenchée par un simple bootstrap read-only.

Invariants¶

Une table possède une responsabilité identifiable.
La base persiste une décision ; elle ne l'invente pas.
Les états intermédiaires restent distinguables des états consolidés.
Les projections restent dérivées et reconstruisibles.
Les états techniques ne deviennent pas des concepts métier.
Les consommateurs ne contournent pas les frontières de lecture/écriture.
Une investigation commence en lecture seule.
Une écriture manuelle en production n'est pas un mécanisme normal de maintenance.