Factory Product¶
Statut¶
Spécification normative du domaine métier Product.
Qu'est-ce qu'une Factory ?¶
Une Factory est un composant chargé de créer un objet métier complexe dans un état valide.
Dans le domaine Product, son rôle est de construire un nouvel agrégat Product sans permettre qu'il naisse déjà incohérent.
L'idée est simple : plutôt que laisser plusieurs endroits du code créer un Product chacun à leur manière, on centralise les règles de création dans un point d'entrée explicite.
Principe central¶
La Factory ne doit jamais créer un Product invalide.
Elle doit soit :
- retourner un Product valide ;
- retourner un échec explicite.
Elle ne doit jamais retourner un Product « presque valide » dont l'état devrait être réparé plus tard.
Invariants à respecter dès la création¶
La Factory doit notamment préserver :
- une identité canonique unique ;
- le fait qu'un identifiant reste une preuve ;
- le fait qu'une observation ne remplace pas silencieusement l'identité ;
- le fait qu'une variante appartienne à exactement un Product.
Ce que la Factory doit faire¶
Elle doit :
- vérifier les données nécessaires à la création ;
- initialiser explicitement l'état de cohérence ;
- refuser une identité trop ambiguë lorsque le contrat l'exige ;
- produire un objet métier conforme aux invariants dès sa naissance.
Ce qu'elle ne doit pas faire¶
Elle ne doit pas :
- inventer silencieusement une identité à partir d'informations insuffisantes ;
- ignorer les règles de validation ;
- écrire elle-même dans la base de données ;
- dépendre du parsing d'un feed ;
- dépendre d'un marchand particulier.
Exemple concret¶
Supposons qu'un import apporte :
marque : Samsung
modèle : inconnu
EAN : absent
Si les règles Product exigent davantage de preuves pour créer une identité canonique fiable, la Factory ne doit pas fabriquer arbitrairement un Product Samsung inconnu simplement pour que le traitement continue.
Elle doit rendre un résultat explicite permettant au système de traiter le cas comme incomplet, ambigu ou rejeté selon le contrat en vigueur.
Factory ≠ Repository¶
Ces deux notions sont différentes :
Factory
→ crée un Product valide
Repository
→ enregistre ou retrouve un Product
La Factory ne persiste pas. Le Repository ne décide pas comment créer correctement l'objet métier.
Factory ≠ Resolver¶
Le Resolver établit ou confirme une identité à partir de preuves.
La Factory construit l'agrégat à partir d'un état déjà suffisamment validé pour la création.
Selon le cas d'usage, un Resolver peut donc intervenir avant la Factory.
Comment diagnostiquer un Product mal créé¶
Si un Product paraît incohérent dès son apparition :
- retrouver les données d'entrée utilisées ;
- vérifier si une résolution d'identité a eu lieu ;
- vérifier les validations appliquées par la Factory ;
- comparer le résultat avec les invariants Product ;
- corriger la règle responsable plutôt que réparer manuellement chaque Product déjà créé.
Pour une personne qui reprend le projet¶
Quand tu rencontres Factory, pense :
« constructeur métier sécurisé ».
Son objectif n'est pas d'être pratique, mais d'empêcher que des objets invalides entrent dans le domaine.
Décision¶
La Factory est le point d'entrée officiel pour créer un Product dans un état métier valide.