Invariants¶
Les invariants définissent les règles absolues de CMonChoix Platform.
Ils ne sont pas des recommandations. Ils constituent des contraintes d'architecture qui ne doivent jamais être violées.
Sommaire¶
- Définition
- Pourquoi des invariants ?
- Invariants du Domain Core
- Invariants des Vertical Modules
- Invariants du Pipeline
- Invariants du Runtime
- Invariants du Frontend
- Invariants des Read Services
- Invariants des Write Services
- Invariants des migrations
- Ce qui est interdit
- Voir aussi
Définition¶
Un invariant est une propriété qui doit rester vraie quelle que soit l'évolution du projet.
Contrairement à une règle métier, un invariant ne change pas lorsqu'une nouvelle verticale est ajoutée.
Les invariants constituent le contrat architectural de la Platform.
Pourquoi des invariants ?¶
À mesure que le projet grandit, il devient facile de créer des dépendances implicites ou de déplacer de la logique métier au mauvais endroit.
Les invariants servent à empêcher ces dérives.
Ils garantissent que toutes les futures évolutions restent compatibles avec l'architecture générale.
Invariants du Domain Core¶
Le Domain Core :
- ne connaît jamais les verticales ;
- ne connaît jamais le frontend ;
- ne connaît jamais les feeds ;
- ne connaît jamais le pipeline ;
- ne connaît jamais le runtime ;
- ne contient que des concepts métier génériques.
Le Domain Core constitue la base commune de toutes les verticales.
Invariants des Vertical Modules¶
Une verticale :
- spécialise le Domain Core ;
- n'en modifie jamais le comportement générique ;
- ne crée jamais de dépendance vers une autre verticale ;
- reste autonome.
Une règle Smartphone ne doit jamais être visible depuis Photo, TV ou Gaming.
Invariants du Pipeline¶
Le Pipeline :
- transforme les données ;
- enrichit les données ;
- prépare les projections.
Il ne contient pas la vérité métier.
Il ne doit jamais remplacer le Domain Core.
Invariants du Runtime¶
Le Runtime :
- orchestre les traitements ;
- exécute les workflows ;
- applique les décisions validées.
Il ne crée pas de nouvelles règles métier.
Invariants du Frontend¶
Le Frontend :
- affiche les projections ;
- ne recalculera jamais une identité ;
- ne recalculera jamais un score qualité ;
- ne dépend jamais directement des feeds.
Toute logique métier appartient aux couches précédentes.
Invariants des Read Services¶
Les Read Services :
- ne modifient jamais la base ;
- n'écrivent jamais ;
-
permettent uniquement :
-
les audits ;
- les simulations ;
- les comparaisons ;
- les rapports ;
- les previews.
Ils sont entièrement read-only.
Invariants des Write Services¶
Les Write Services :
- sont les seuls autorisés à modifier les données métier ;
- doivent être explicites ;
- doivent être auditables ;
- doivent être réversibles autant que possible.
Aucune écriture implicite n'est autorisée.
Invariants des migrations¶
Toute migration :
- est progressive ;
- est documentée ;
- possède une stratégie de rollback ;
- est précédée d'un audit ;
- est suivie d'une validation.
Le legacy n'est supprimé qu'après preuve d'absence d'usage.
Ce qui est interdit¶
Il est interdit de :
- mettre une règle métier dans le Frontend ;
- ajouter une logique de verticale dans le Domain Core ;
- créer une dépendance circulaire ;
- écrire depuis un Read Service ;
- recalculer une vérité métier déjà disponible ;
- modifier directement un feed validé sans mission dédiée ;
- supprimer du legacy sans preuve.
Conclusion¶
Les invariants représentent les fondations techniques de CMonChoix Platform.
Ils doivent rester valides indépendamment :
- du nombre de verticales ;
- des marchands ;
- des feeds ;
- des pipelines ;
- du runtime.
Ils garantissent la stabilité de l'architecture sur le long terme.
Voir aussi¶
- Vision
- Principes
- Dépendances
- Identifier First
- Canonical Identity
- Domain Core