Frontière de persistance du Product Domain¶

Statut¶

Spécification de frontière d'architecture.

Pourquoi cette frontière existe¶

Le Product Domain décrit ce qu'est un produit et quelles règles doivent rester vraies. Il ne doit pas savoir comment MariaDB, WordPress, un cache ou une table SQL stockent les informations.

Cette séparation permet de faire évoluer la technique sans réécrire les règles métier.

Règle centrale¶

Product Domain → définit ce qui doit être conservé
Infrastructure → décide comment le conserver techniquement

Le Product Domain exprime donc des contrats et des objets métier. L'infrastructure implémente ensuite le stockage correspondant.

Exemple concret¶

Le métier peut demander :

charger un Product avec son identité, ses variantes, ses observations et ses conflits.

Cette demande ne doit pas devenir dans le domaine :

lire telle colonne de telle table avec telle jointure SQL.

Le détail des tables appartient à l'infrastructure ou à l'adapter de persistance.

Ce qui ne doit jamais entrer dans le Product Domain¶

Le Product Domain ne doit dépendre directement ni de :

SQL ;
noms de tables ;
index ;
ORM ;
WordPress ;
mécanismes de cache ;
HTTP ;
détails de connexion à la base.

ORM signifie Object-Relational Mapping : une couche technique qui traduit des objets vers des lignes de base de données. Même si un ORM est utilisé, il reste un détail de persistance.

Invariants à préserver pendant une écriture¶

Toute implémentation de persistance doit conserver :

l'unicité de l'identité canonique ;
le fait qu'un identifiant reste une preuve et non l'identité à lui seul ;
le fait qu'une observation ne remplace pas silencieusement l'identité ;
l'appartenance d'une variante à un seul Product.

Une écriture techniquement réussie mais qui viole ces règles est une écriture métier incorrecte.

Pour diagnostiquer un problème de stockage¶

Si un Product semble incomplet après relecture :

vérifier que le Product était cohérent avant la persistance ;
vérifier le contrat du Repository ;
vérifier l'implémentation de persistance ;
vérifier que toutes les parties nécessaires de l'agrégat sont relues ;
comparer l'état avant écriture et après relecture.

Éviter de corriger directement une colonne SQL avant d'avoir établi si l'erreur vient du domaine, du Repository ou de l'implémentation de stockage.

Règle de transmission¶

Si une modification du modèle métier oblige soudainement le Product Domain à connaître une table ou une requête SQL précise, la frontière est probablement en train d'être franchie au mauvais endroit.

Décision¶

La persistance reste entièrement à l'extérieur de la frontière métier du Product Domain.