Présentation des Read Services¶

Vue d'ensemble¶

Les Read Services regroupent l'ensemble des services de lecture de la Platform.

Ils permettent d'observer, d'analyser et de comprendre les données sans jamais les modifier.

Contrairement aux composants du Pipeline ou aux futurs Write Services, les Read Services n'ont aucune responsabilité de transformation. Leur unique mission consiste à produire des informations exploitables à partir de l'état actuel de la Platform.

Ils constituent l'un des principaux outils d'industrialisation de CMonChoix.

Pourquoi des Read Services ?¶

L'évolution d'une plateforme manipulant plusieurs centaines de milliers de produits ne peut pas reposer uniquement sur l'observation du résultat final.

Avant toute modification du Domain Core, d'une verticale ou du Pipeline, il est indispensable de comprendre précisément l'état des données.

Les Read Services répondent à ce besoin.

Ils permettent notamment de :

analyser les données produites par le Pipeline ;
comparer plusieurs versions d'un traitement ;
mesurer l'impact d'une évolution ;
identifier les anomalies ;
produire des indicateurs de qualité ;
préparer une intervention sans modifier les données.

Cette approche limite fortement les risques de régression.

Une architecture orientée observation¶

Les Read Services reposent sur un principe simple :

Observer avant de modifier.

Chaque évolution importante de la Platform suit le même cycle :

Observation
        │
        ▼
Analyse
        │
        ▼
Compréhension
        │
        ▼
Simulation
        │
        ▼
Validation
        │
        ▼
Modification éventuelle

L'objectif est de ne jamais corriger un problème qui n'a pas été parfaitement identifié.

Lecture seule¶

Tous les Read Services sont strictement read-only.

Ils peuvent :

lire des données ;
effectuer des calculs ;
produire des rapports ;
générer des statistiques ;
comparer plusieurs états.

En revanche, ils ne doivent jamais :

modifier une table ;
mettre à jour une projection ;
corriger une donnée ;
lancer une synchronisation ;
déclencher un traitement métier.

Cette règle constitue l'un des invariants majeurs de la Platform.

Position dans l'architecture¶

Les Read Services consomment les composants du Domain Core afin d'exposer des informations exploitables.

                Domain Core
                      │
                      ▼
               Read Services
                      │
          ┌───────────┼───────────┐
          ▼           ▼           ▼
      Audits     Simulations    Rapports

Ils peuvent également utiliser des Vertical Modules lorsque l'analyse concerne une famille de produits spécifique.

Principales responsabilités¶

Les Read Services permettent notamment de :

inspecter les données normalisées ;
analyser les identités canoniques ;
comparer deux traitements ;
mesurer les KPI ;
produire des rapports de validation ;
générer des simulations ;
préparer des micro-correctifs ;
documenter les résultats d'une évolution.

Ils ne participent jamais directement au fonctionnement du Frontend.

Une brique essentielle de l'industrialisation¶

Les Read Services occupent une place centrale dans la méthode industrielle de CMonChoix.

Avant toute évolution importante :

les données sont observées ;
les écarts sont identifiés ;
les KPI sont mesurés ;
les hypothèses sont validées ;
les simulations sont réalisées ;
les résultats sont documentés.

Ce n'est qu'après cette phase qu'une modification du code peut être envisagée.

Cette démarche permet d'éviter les corrections empiriques et de conserver un Domain Core stable.

Types de Read Services¶

La Platform regroupe plusieurs familles de Read Services.

Audits¶

Les audits permettent d'analyser précisément un comportement particulier de la Platform.

Ils répondent généralement à une question métier ou technique.

Exemples :

pourquoi deux produits ne fusionnent-ils pas ?
quels conflits restent présents ?
quelles familles génèrent le plus d'erreurs ?

Simulations¶

Les simulations permettent de tester une évolution sans modifier les données réelles.

Elles reproduisent le comportement attendu afin d'évaluer les conséquences d'un changement.

Cette approche est largement utilisée lors de l'industrialisation d'une nouvelle verticale.

Comparaisons¶

Les services de comparaison confrontent plusieurs états de la Platform.

Ils peuvent comparer :

Legacy contre Platform ;
avant / après un patch ;
plusieurs stratégies de résolution ;
plusieurs versions d'un algorithme.

Ils facilitent la validation des évolutions.

Rapports¶

Les rapports synthétisent les résultats obtenus.

Ils sont destinés aux développeurs, aux architectes et aux opérateurs.

Ils permettent notamment de conserver une trace des validations réalisées.

Dumps¶

Les dumps produisent une représentation lisible des données afin de faciliter leur inspection.

Ils sont particulièrement utiles lors de l'analyse d'identités complexes ou de conflits difficiles à reproduire.

Dépendances autorisées¶

Les Read Services peuvent dépendre :

du Domain Core ;
des Contracts ;
des Vertical Modules (si nécessaire).

Ils ne doivent jamais dépendre :

du Frontend ;
du Runtime ;
des Write Services.

Cette séparation garantit leur indépendance.

Évolution¶

À mesure que de nouvelles verticales seront intégrées, les Read Services continueront de s'enrichir.

L'objectif n'est pas d'accumuler des outils ponctuels, mais de construire une bibliothèque cohérente de services d'observation réutilisables dans l'ensemble de la Platform.

Chaque nouveau Read Service doit répondre à un besoin clairement identifié et rester conforme au principe fondamental de cette couche :

Comprendre avant d'agir.