Vision¶
Objectif : définir la vision globale de CMonChoix Platform et les principes qui guideront toutes les évolutions futures du projet.
Sommaire¶
- Pourquoi une nouvelle architecture ?
- Les objectifs
- Les principes fondateurs
- La vision à long terme
- Les bénéfices attendus
- Les non-objectifs
- Les preuves de concept
- L'état actuel
- Les prochaines étapes
- Voir aussi
Pourquoi une nouvelle architecture ?¶
CMonChoix est devenu un projet suffisamment vaste pour nécessiter une séparation claire entre les différents niveaux de responsabilité.
L'objectif n'est plus uniquement de synchroniser des catalogues marchands, mais de construire une plateforme capable de gérer durablement un grand nombre de verticales produits tout en conservant une architecture stable, testable et évolutive.
La Platform constitue cette nouvelle couche d'abstraction.
Elle permet de séparer :
- les concepts métier génériques ;
- les règles propres à chaque verticale ;
- les traitements d'ingestion ;
- les services de lecture ;
- les services d'écriture ;
- le runtime ;
- le frontend.
Cette séparation réduit les couplages, limite les régressions et facilite les évolutions futures.
Les objectifs¶
La Platform poursuit plusieurs objectifs majeurs.
1. Une vérité métier unique¶
Toute information métier importante doit avoir une seule source de vérité.
Par exemple :
- l'identité canonique d'un produit ;
- son score qualité ;
- son état de santé ;
- sa projection ;
- ses promotions.
Aucune logique ne doit être dupliquée dans plusieurs couches.
2. Une architecture modulaire¶
Chaque composant possède une responsabilité clairement définie.
Chaque couche peut évoluer indépendamment des autres.
Les dépendances sont volontairement limitées.
3. Une architecture évolutive¶
L'ajout d'une nouvelle verticale ne doit jamais nécessiter de modifier le Domain Core.
Une verticale doit uniquement spécialiser le comportement générique.
4. Une architecture testable¶
Chaque composant doit pouvoir être audité indépendamment.
Les Read Services permettent de comparer, simuler et mesurer les résultats sans modifier les données.
5. Une architecture durable¶
L'objectif n'est pas uniquement de résoudre les besoins actuels.
La Platform doit rester pertinente pendant de nombreuses années malgré l'évolution des catalogues, des marchands et des verticales.
Les principes fondateurs¶
La Platform repose sur quelques principes simples.
Identifier First¶
L'identité d'un produit ne repose plus uniquement sur son EAN.
Elle est déterminée à partir de plusieurs identifiants et signaux métier.
Canonical Product Identity¶
Chaque produit possède une identité canonique unique.
Cette identité devient la référence commune de toutes les couches.
Séparation des responsabilités¶
Chaque couche possède une responsabilité clairement définie.
Une couche ne doit jamais réaliser le travail d'une autre.
Lecture avant écriture¶
Toute évolution importante commence par :
- un audit ;
- une simulation ;
- une comparaison.
L'écriture n'intervient qu'après validation.
Compatibilité progressive¶
La migration vers la Platform est incrémentale.
Le legacy continue de fonctionner tant que la nouvelle architecture n'est pas complètement validée.
Vision à long terme¶
À terme, la Platform devra permettre de gérer un nombre important de verticales partageant exactement le même socle métier.
Platform
│
├── Domain Core
│
├── Read Services
│
├── Write Services
│
├── Vertical Modules
│
├── Pipeline
│
├── Runtime
│
├── Frontend
│
└── Interfaces
Chaque verticale apporte uniquement ses règles spécifiques.
Le reste est mutualisé.
Verticales prévues¶
À terme, la Platform devra permettre de gérer notamment :
- Smartphone
- Photo
- TV
- Audio
- Gaming
- Printer
- GPU
- Informatique
- Mobility
- Toys
- Wellness
- Électroménager
- Maison
- ainsi que les futures verticales encore inconnues.
Les bénéfices attendus¶
Cette architecture apporte plusieurs avantages.
Stabilité¶
Les changements d'une verticale n'impactent pas les autres.
Réutilisabilité¶
Le Domain Core est partagé entre toutes les verticales.
Industrialisation¶
Une nouvelle verticale nécessite beaucoup moins de développement.
Maintenabilité¶
Les responsabilités sont clairement séparées.
Testabilité¶
Chaque composant peut être validé indépendamment.
Les non-objectifs¶
La Platform n'a pas pour objectif :
- de remplacer brutalement le système historique ;
- de supprimer immédiatement le legacy ;
- de réécrire tout le pipeline ;
- de casser les traitements existants.
La migration est progressive.
Les preuves de concept¶
Deux verticales servent actuellement de validation.
| Verticale | Statut | Objectif |
|---|---|---|
| Smartphone | Validée opérationnellement | Première preuve de concept |
| Photo | Validée en lecture | Validation multi-verticale |
Les deux démontrent que le Domain Core peut être partagé.
État actuel¶
La structure générale de la Platform est désormais en place.
Le Domain Core est fonctionnel.
Les Read Services sont disponibles.
Les premiers Vertical Modules sont créés.
Le Runtime historique reste utilisé tant que la Platform n'est pas entièrement validée.
Prochaines étapes¶
Les prochaines phases du projet sont :
- Finaliser la documentation.
- Compléter le Domain Core.
- Généraliser les Vertical Modules.
- Développer progressivement les Write Services.
- Brancher le Runtime via des wrappers.
- Industrialiser l'ensemble des verticales.
Voir aussi¶
- Principes
- Invariants
- Dépendances
- Identifier First
- Canonical Identity
- Domain Core
- Pipeline
- Runtime