Database Overview¶
La couche Database constitue le socle de persistance de CMonChoix Platform.
Elle ne représente pas la logique métier de la plateforme. Son rôle est de conserver durablement les données produites par les différentes couches de traitement, d'assurer leur traçabilité et de fournir des structures stables pour les services de lecture, le Runtime et le Frontend.
Conformément aux principes de l'architecture Platform, la base de données ne décide jamais de la vérité métier. Celle-ci est construite par le Domain Core puis matérialisée sous forme de projections persistées.
Objectifs¶
La couche Database poursuit plusieurs objectifs :
- assurer une persistance fiable des données importées
- séparer les différentes étapes du pipeline
- conserver un historique des traitements
- faciliter les audits
- permettre la reconstruction des projections
- offrir des structures stables au Runtime et au Frontend
- limiter les couplages entre les différentes couches de la plateforme
La base de données constitue donc une représentation persistante de l'état courant de la Platform, et non l'origine de la logique métier.
Principes d'architecture¶
La conception de la couche Database repose sur plusieurs invariants.
Séparation des responsabilités¶
Chaque table possède une responsabilité clairement définie.
Une table ne doit jamais cumuler plusieurs rôles fonctionnels.
Par exemple :
- une table de stage ne devient jamais une table métier
- une table de projection ne devient jamais une table de logs
- une table d'historique ne devient jamais une table de travail
Cette séparation simplifie les audits et réduit les effets de bord.
Pipeline progressif¶
Les données traversent plusieurs états successifs.
Feed marchand
│
▼
Import brut
│
▼
Stage
│
▼
Normalisation
│
▼
Canonical Identity
│
▼
Projection
│
▼
Frontend
Chaque étape possède ses propres structures de données.
Aucune étape ne modifie rétroactivement les responsabilités d'une étape précédente.
Persistance des projections¶
Le Frontend ne lit jamais directement les données de stage.
Il consomme uniquement des données déjà préparées.
Cette règle permet :
- des temps de réponse stables
- une logique Frontend minimale
- une reproductibilité des résultats
- une meilleure évolutivité
Voir également :
Catégories de données¶
La base de données est organisée autour de plusieurs familles de données.
Données d'import¶
Ces tables représentent les informations reçues des marchands.
Caractéristiques :
- proches du feed d'origine
- peu transformées
- fortement traçables
- réimportables
Elles constituent le point d'entrée du pipeline.
Données de traitement¶
Ces données sont enrichies progressivement.
Elles servent notamment à :
- normaliser les attributs
- résoudre les identifiants
- produire la Canonical Identity
- calculer les indicateurs de qualité
Ces structures sont principalement consommées par le Domain Core.
Voir :
Données projetées¶
Les projections représentent les données prêtes à être consommées.
Leur objectif est de fournir :
- une structure stable
- un accès rapide
- un modèle optimisé pour la lecture
Les projections ne recalculent jamais la logique métier.
Données techniques¶
Certaines tables servent uniquement au fonctionnement de la plateforme.
Exemples :
- historique des synchronisations
- fichiers téléchargés
- états d'exécution
- caches techniques
- journaux d'exécution
Ces données ne participent pas directement au modèle métier.
Tables de référence¶
La Platform s'appuie sur plusieurs tables majeures documentées dans les volumes d'architecture. :contentReference[oaicite:0]{index=0}
Stage¶
Cette famille contient les données importées avant normalisation.
Responsabilités :
- conserver le contenu du feed
- permettre les audits
- reproduire une synchronisation
- comparer plusieurs imports
Elle représente toujours l'état brut d'un produit.
Offres normalisées¶
Cette famille contient les données transformées par le pipeline.
On y retrouve notamment :
- identifiants normalisés
- attributs harmonisés
- informations enrichies
- résultats de résolution
Ces données servent de base aux projections.
Historique des synchronisations¶
Ces structures permettent de conserver :
- les exécutions
- les dates
- les états
- les statistiques
- les éventuelles erreurs
Elles sont utilisées par les outils d'exploitation.
Voir :
Cache de navigation¶
Le cache de navigation fournit une représentation optimisée des catégories destinées au Frontend.
Il évite de reconstruire l'arborescence à chaque requête.
Sa reconstruction reste entièrement contrôlée par les traitements de la Platform.
Flux de données¶
Le cycle de vie d'une donnée suit toujours le même principe.
Import
│
▼
Stage
│
▼
Normalisation
│
▼
Enrichissement
│
▼
Canonical Identity
│
▼
Projection
│
▼
Persistance
│
▼
Lecture
Une étape ne doit jamais être contournée.
Invariants¶
La couche Database respecte plusieurs règles fondamentales.
La base ne décide jamais¶
Une information présente dans une table n'est jamais considérée comme vraie uniquement parce qu'elle existe.
La vérité métier est déterminée par :
- le Domain Core
- les Vertical Modules
- les règles de résolution
La base de données ne fait que conserver ce résultat.
Aucune logique Frontend¶
Le Frontend ne doit jamais :
- compléter les données
- recalculer une identité
- reconstruire une projection
- résoudre un conflit métier
Toutes ces opérations sont réalisées avant la persistance.
Données auditables¶
Chaque traitement doit pouvoir être vérifié.
Les structures de données doivent permettre :
- la comparaison entre deux exécutions
- l'analyse d'une régression
- la reproduction d'un traitement
- l'explication d'un résultat
Cette propriété est indispensable à la méthode industrielle de CMonChoix.
Structures stables¶
Les consommateurs des données doivent pouvoir évoluer indépendamment.
Une évolution de la base ne doit pas casser :
- le Runtime
- le Frontend
- les Read Services
Lorsque cela est nécessaire, la compatibilité est assurée par les couches applicatives plutôt que par une modification brutale du schéma.
Dépendances¶
La couche Database est utilisée par :
- le Pipeline
- les Read Services
- les Write Services
- le Runtime
- le Frontend (uniquement via les projections)
En revanche, elle ne dépend jamais :
- d'une verticale particulière
- d'une logique d'affichage
- d'une politique métier spécifique
Garde-fous¶
Afin de préserver la cohérence des données, plusieurs règles doivent toujours être respectées.
- aucune logique métier directement dans le schéma SQL
- aucune dépendance circulaire entre composants applicatifs
- aucune lecture du stage par le Frontend
- aucune modification manuelle des projections en production
- séparation stricte entre données techniques et données métier
- conservation des historiques nécessaires aux audits
Évolutions futures¶
La couche Database est conçue pour accompagner l'évolution progressive de la Platform.
Les principales orientations sont :
- enrichissement progressif des projections
- amélioration des structures de lecture
- spécialisation des Write Services
- optimisation des performances de consultation
- extension des caches techniques lorsque cela apporte un bénéfice mesurable
Ces évolutions devront conserver les invariants décrits dans ce document.