VO-10 · Le modèle de données sert le modèle du domaine
Signal
- Un concept devenu entity, avec un id dans le domaine, seulement parce qu’il est rangé dans sa propre table.
- L’id technique de cette table visible dans le domaine.
- Un modèle du domaine façonné par la normalisation, les clés étrangères ou les besoins de reporting.
Pourquoi
Le modèle de données se conçoit à partir du modèle du domaine, jamais l’inverse. Sinon, le domaine se contente de recopier les tables.
Pour savoir si un concept rangé dans sa propre table est une entity ou un value object, se poser quatre questions :
- Le concept décrit-il autre chose, au lieu d’exister pour lui-même ? Une adresse décrit où habite le titulaire.
- Se compare-t-il par sa valeur ? Deux adresses identiques sont interchangeables.
- Pense-t-on en faire une entity seulement parce qu’il a sa propre table ?
- Le métier a-t-il besoin de le suivre dans le temps, sous une identité propre ?
Trois « oui » puis un « non » : c’est un value object, quelle que soit la façon dont la base le range.
Exceptions
Les clés étrangères, les index et le reporting ont leur place dans le modèle de données, mais ils ne décident pas de la forme du modèle du domaine. Un modèle de données séparé pour le reporting est recommandé.
Correction
- Une valeur simple va dans la ligne de son parent (dénormalisée).
- Une collection est sérialisée dans une colonne, ou va dans une table enfant dont l’id technique reste caché.
Adaptation
Sérialiser une collection dans une colonne est souvent écarté : la colonne peut être trop étroite, et on ne peut pas l’interroger. Avec PostgreSQL et une colonne JSONB, ces deux limites pèsent beaucoup moins.
Voir aussi
ENT-08 cache l’id technique. AGG-14 préfère des value objects comme parties d’un aggregate.