Invariants du domaine Feed¶

Statut¶

Spécification métier normative.

Pourquoi cette page existe¶

Les invariants du domaine Feed définissent les règles qui ne doivent pas être violées lors de la réception d'une publication marchand.

Une politique ou une implémentation peut évoluer. Un invariant, lui, représente une loi métier durable. S'il change, cela signifie que le modèle même du domaine Feed a été redéfini.

Source, publication, import : trois notions différentes¶

Ces termes sont proches mais ne désignent pas la même chose.

Source¶

La source représente l'origine stable d'une publication dans la plateforme.

Elle ne doit pas être confondue avec une publication précise, ni avec l'import qui la traite.

Publication¶

La publication représente ce que la source a publié à un instant donné.

Elle doit rester distincte de l'import qui vient ensuite la prendre en charge.

Import¶

L'import est l'opération qui prend en charge cette publication dans CMonChoix.

Chaque import doit être identifiable de manière unique et traçable jusqu'à sa source et sa publication.

Invariant du lot brut¶

Le lot brut importé doit rester fidèle à la publication d'origine.

Il ne doit pas introduire silencieusement :

une correction ;
une interprétation ;
une normalisation ;
un enrichissement.

Le but est de conserver une preuve fiable de ce qui a réellement été reçu avant toute transformation.

Pourquoi cette séparation est importante¶

Imaginons qu'un titre produit soit incorrect plus tard dans le pipeline.

Si le lot brut a été conservé sans modification, on peut comparer :

Publication reçue
      ↓
Lot brut
      ↓
Stage
      ↓
Normalisation
      ↓
Projection

On peut alors déterminer précisément à quel moment la valeur a changé.

Sans cette séparation, le diagnostic devient beaucoup plus difficile.

Métadonnées minimales obligatoires¶

Un import doit conserver suffisamment de métadonnées pour expliquer :

d'où vient la publication ;
quel marchand est concerné ;
quand l'import a eu lieu ;
quel résultat a été observé.

Ces métadonnées ne doivent pas contenir une interprétation produit qui appartient aux couches suivantes.

Résultat d'import¶

Le résultat d'un import doit rester explicite et compréhensible.

Un import ne doit pas se contenter de disparaître ou de sembler réussir sans information exploitable.

Lorsque quelque chose se passe mal, le domaine doit fournir un résultat identifiable : échec, rejet ou résultat partiellement exploitable selon le contrat prévu.

Frontière stricte avec les couches suivantes¶

Le domaine Feed ne doit pas contenir :

de normalisation ;
de résolution d'identité ;
de projection ;
d'interprétation produit ;
d'orchestration Runtime ;
de logique d'adapter ;
de détails d'infrastructure.

Aucune interprétation métier produit ne doit être introduite avant le Stage.

Que faire lorsqu'un invariant est violé ?¶

Une violation ne doit jamais être ignorée silencieusement.

Le domaine doit produire un résultat explicite, par exemple :

refuser l'entrée ;
retourner un échec d'import ;
retourner un résultat rejeté ;
signaler qu'une partie seulement est exploitable.

L'objectif est toujours de rendre l'état observable et diagnosticable.

Exemple de reprise¶

Si une synchronisation d'un marchand échoue, commence par vérifier :

si la source est bien identifiée ;
si la publication reçue est connue ;
si l'import possède un identifiant stable ;
si le lot brut est disponible et fidèle ;
si le résultat d'import explique clairement l'échec.

Si ces cinq points sont corrects, l'enquête peut continuer vers le Stage ou le Pipeline.

Décision d'architecture¶

Décision : FOUNDATION

Ces invariants constituent le contrat normatif le plus strict du domaine Feed. Les futurs Value Objects, politiques, événements, tests et contrats de ce domaine doivent rester compatibles avec ces règles.