Projections du Product Domain¶

Statut¶

Spécification normative de modèle de lecture.

Qu'est-ce qu'une projection ?¶

Une projection est une représentation dérivée des données métier, préparée pour être lue facilement par un consommateur.

Elle existe pour éviter que le frontend, une API ou un audit aient à reconstruire toute la logique du Product Domain à chaque lecture.

Règle centrale¶

Une projection n'est pas la vérité métier.

La vérité reste dans le Product Domain. La projection est une vue reconstruisible à partir de cet état.

Product Domain
      ↓
Projection Builder
      ↓
Projection
      ↓
Frontend / API / audit / export

Pourquoi cette séparation est importante¶

Une vue d'affichage peut avoir besoin d'informations déjà organisées : nom, marque, modèle, statut de cohérence, variantes, conflits, etc.

Préparer ces données en amont permet des lectures rapides, mais la projection ne doit pas devenir l'endroit où l'on invente une identité ou où l'on cache un conflit.

Types de projections¶

Product Summary Projection¶

Vue synthétique pouvant contenir :

nom ;
marque ;
modèle ;
catégorie ou regroupement de lecture ;
statut de cohérence.

Elle convient aux listes et résumés.

Product Detail Projection¶

Vue détaillée pouvant exposer :

identité complète ;
variantes ;
identifiants ;
observations ;
conflits.

Product Conflict Projection¶

Vue spécialisée pour l'audit :

liste des conflits ;
preuves associées ;
état de résolution.

Ce qu'une projection peut faire¶

Elle peut :

sélectionner des champs ;
organiser les informations ;
agréger des données déjà décidées ;
préparer une structure de lecture efficace.

Ce qu'elle ne doit jamais faire¶

Elle ne doit pas :

créer une nouvelle identité ;
résoudre un conflit ;
modifier le Product ;
introduire une règle métier cachée ;
devenir irremplaçable ou impossible à reconstruire.

Exemple concret¶

Supposons que la page d'un smartphone affiche un mauvais modèle.

Avant de corriger la projection, il faut vérifier :

l'identité canonique du Product ;
l'état qui a servi à construire la projection ;
la logique du Projection Builder ;
la date ou version de reconstruction ;
le consommateur final.

Si l'identité canonique est correcte mais la projection fausse, le problème appartient à la construction ou à l'actualisation de la projection — pas au Product Domain lui-même.

Règles¶

Les projections doivent :

être reconstruisibles ;
dériver uniquement de données autoritatives ;
rester en lecture ;
ne jamais modifier le Product ;
ne pas contenir de nouvelle décision métier.

Pour la reprise du projet¶

Face à une donnée publique incorrecte, ne pars jamais du principe que « la valeur en base affichée par le frontend est la vérité ». Remonte d'abord jusqu'à la source autoritative.

Une projection peut être périmée, mal reconstruite ou mal consommée.

Décision¶

Les projections sont des représentations optimisées pour la lecture, et non des propriétaires de la vérité métier.