Contracts¶

Les Contracts définissent les interfaces, conventions et frontières entre les couches de CMonChoix Platform.

Ils stabilisent les échanges entre le Domain Core, les Vertical Modules, les Read Services, les Write Services, le Pipeline et le Runtime.

Sommaire¶

Rôle
Pourquoi des Contracts ?
Responsabilités
Ce que les Contracts contiennent
Ce qu'ils ne contiennent pas
Contrats prévus
Cycle de maturité
Règle importante
Voir aussi

Rôle¶

Les Contracts sont la couche de stabilisation de la Platform.

Ils permettent de définir :

ce qu'une couche peut attendre d'une autre ;
quelles données doivent être échangées ;
quelles responsabilités sont garanties ;
quelles dépendances sont autorisées.

Un Contract ne doit pas contenir de logique métier lourde.

Il définit une forme, une convention ou une interface.

Pourquoi des Contracts ?¶

Sans Contracts, chaque couche pourrait commencer à appeler directement une autre couche de manière implicite.

À long terme, cela rendrait l'architecture fragile.

Les Contracts servent donc à protéger la Platform contre :

les dépendances circulaires ;
les appels directs non maîtrisés ;
la duplication de logique ;
le couplage entre verticales ;
l'instabilité des signatures internes.

Responsabilités¶

Les Contracts sont responsables de :

définir des interfaces stables ;
documenter les échanges entre couches ;
normaliser les entrées et sorties ;
réduire le couplage ;
préparer les futures extensions.

Ils ne sont pas responsables de :

résoudre une identité produit ;
scorer une verticale ;
modifier la base ;
orchestrer le runtime ;
afficher une page frontend.

Ce que les Contracts contiennent¶

Les Contracts peuvent contenir :

interfaces ;
structures de données ;
conventions de nommage ;
statuts normalisés ;
types de résultats ;
règles minimales d'appel.

Ce qu'ils ne contiennent pas¶

Les Contracts ne doivent jamais contenir :

une règle métier Smartphone ;
une règle métier Photo ;
une règle spécifique à un feed ;
une écriture SQL ;
une logique frontend ;
une logique runtime.

Contrats prévus¶

Les premiers contrats envisagés sont :

Contract	Rôle
Identity Resolver	Définir la résolution d'identité
Projection Builder	Définir la construction des projections
Conflict Policy	Encadrer les règles de conflit
Quality Scorer	Encadrer les scores qualité
Write Service	Encadrer les écritures métier

Cycle de maturité¶

Un Contract ne doit pas être créé trop tôt.

La règle recommandée est :

1 verticale
    ↓
besoin local

2 verticales
    ↓
besoin commun confirmé

3 verticales
    ↓
contract stable

Cette règle évite de créer des contrats trop influencés par une seule verticale.

Règle importante¶

Un Contract est créé uniquement lorsqu'un besoin commun est prouvé.

Il ne doit jamais être inventé par anticipation excessive.

État actuel¶

La couche contracts est encore peu remplie.

C'est volontaire.

Les preuves Smartphone et Photo ont permis d'identifier les premiers besoins, mais les contrats définitifs doivent émerger progressivement avec TV, Gaming, Printer et les autres verticales.