Aller au contenu

Value Objects du domaine Feed

Statut

Spécification métier normative.

Qu'est-ce qu'un Value Object ?

Un Value Object est un objet métier défini par sa valeur, et non par une identité propre qui évoluerait dans le temps.

Dit autrement : deux Value Objects contenant exactement les mêmes valeurs représentent le même concept métier.

Dans le domaine Feed, ces objets servent à transporter une information stable et explicite sur un import sans dépendre de WordPress, de SQL, du Runtime ou du frontend.

Règles communes

Les Value Objects du domaine Feed doivent être :

  • immutables : une fois créés, leurs valeurs ne changent pas ;
  • comparables par valeur ;
  • valides dès leur création ;
  • indépendants de l'infrastructure ;
  • indépendants des adapters ;
  • indépendants du frontend ;
  • indépendants de l'orchestration Runtime.

Pourquoi l'immutabilité est utile

Si l'identifiant ou les métadonnées d'un import pouvaient changer silencieusement après coup, un audit ne pourrait plus reconstruire fidèlement ce qui s'est passé.

L'immutabilité protège donc la traçabilité.

MerchantImportId

MerchantImportId identifie un import précis dans CMonChoix.

Il doit être :

  • non vide ;
  • stable une fois attribué ;
  • comparable par valeur.

Exemple

Si un même fichier marchand est importé deux fois dans deux runs distincts, chaque import peut posséder son propre MerchantImportId afin de distinguer les deux exécutions.

Ce Value Object ne décrit pas le produit contenu dans le feed. Il identifie uniquement l'opération d'import.

MerchantImportMetadata

MerchantImportMetadata décrit le contexte minimal nécessaire pour comprendre et tracer un import.

Il peut contenir notamment :

  • l'identifiant de l'import ;
  • l'identifiant de la source ;
  • l'identifiant du marchand ;
  • la date et l'heure de l'import ;
  • éventuellement la version de la publication ;
  • éventuellement la taille du lot.

Il ne doit pas contenir :

  • le contenu brut complet ;
  • une interprétation produit ;
  • l'état de normalisation ;
  • l'état d'une projection.

Pourquoi cette limite ?

Les métadonnées répondent à la question « dans quel contexte cet import a-t-il eu lieu ? ». Elles ne doivent pas devenir un second modèle produit caché.

MerchantImportResult

MerchantImportResult décrit le résultat de l'import.

Les statuts conceptuels attendus sont :

  • succeeded : import réussi ;
  • failed : import échoué ;
  • rejected : import refusé ;
  • partially_usable : import seulement partiellement exploitable.

Les états failed et rejected doivent fournir une raison minimale explicite.

Ce résultat ne doit jamais :

  • modifier le lot importé ;
  • interpréter les produits ;
  • effectuer une normalisation.

Exemple complet

On peut imaginer le scénario suivant :

Source : feed Samsung
Publication : fichier publié le 10 août
Import : MerchantImportId = abc123
Métadonnées : marchand Samsung, date 10 août, 42 000 lignes
Résultat : succeeded
Lot brut : contenu fidèle à la publication

À ce stade, CMonChoix sait ce qui a été reçu et dans quel contexte, mais n'a pas encore décidé quel produit canonique correspond à chaque ligne.

Comment utiliser ces objets pour diagnostiquer un problème

Si un import semble incohérent :

  1. retrouver le MerchantImportId ;
  2. vérifier les MerchantImportMetadata ;
  3. lire le MerchantImportResult ;
  4. comparer le lot brut à la publication ;
  5. seulement ensuite poursuivre l'analyse dans le Stage ou le Pipeline.

Cette méthode permet de ne pas mélanger un problème d'import avec un problème de normalisation ou d'identité produit.

Décision d'architecture

Décision : FOUNDATION

Le domaine Feed définit d'abord son vocabulaire métier minimal et immuable avant d'introduire des entités, services ou contrats supplémentaires.

Voir aussi