Aggregate Product¶
Statut¶
Spécification normative du domaine métier Product.
Qu'est-ce qu'un Aggregate ?¶
Dans le vocabulaire DDD (Domain-Driven Design), un Aggregate est un groupe cohérent d'objets métier qui doivent respecter leurs règles ensemble.
L'Aggregate Root est l'objet principal par lequel passent les modifications importantes de ce groupe.
Dans CMonChoix, l'Aggregate Root du domaine Product est Product.
Pourquoi cette règle existe¶
Sans Aggregate Root, plusieurs parties du code pourraient modifier directement l'identité, les variantes ou les conflits d'un produit chacune de leur côté.
On obtiendrait vite des états impossibles à expliquer :
Une variante dit A
L'identité canonique dit B
Une observation dit C
Une écriture SQL a modifié D directement
L'Aggregate impose au contraire une frontière de cohérence : les changements importants passent par Product, qui protège les invariants du domaine.
Ce que Product protège¶
L'Aggregate Product est responsable notamment de :
- créer et conserver une identité Product stable ;
- protéger la
Canonical Product Identity; - rattacher les identifiants comme preuves ;
- rattacher les observations ;
- organiser les variantes ;
- représenter les conflits ;
- exposer l'état de cohérence ;
- produire les événements métier utiles.
Exemple concret¶
Supposons qu'une nouvelle observation marchand indique qu'un téléphone possède 512 Go alors que le Product actuellement identifié correspond à une variante 256 Go.
La bonne réaction n'est pas :
UPDATE ... SET storage = 512
La nouvelle information doit être traitée comme une observation et une preuve. Le domaine peut alors déterminer s'il s'agit :
- d'une autre variante ;
- d'une mauvaise observation ;
- d'un conflit ;
- d'un autre Product.
Cette décision doit respecter les invariants avant qu'une écriture persistante soit appliquée.
Ce qui doit passer par Product¶
Les modifications concernant les éléments suivants ne doivent pas contourner l'Aggregate Root :
- identité ;
- variantes ;
- observations ;
- identifiants ;
- conflits.
Cela ne signifie pas que Product doit faire du SQL ou connaître WordPress. Il protège les règles métier ; la persistance appartient à une autre couche.
Ce que l'Aggregate ne possède pas¶
L'Aggregate Product ne gère pas :
- les prix ;
- le stock ;
- les promotions ;
- les offres marchands ;
- le rendu frontend ;
- les requêtes HTTP ;
- le scheduling ;
- le stockage SQL concret.
Relation avec Repository et Write Service¶
On peut résumer le chemin ainsi :
Use case / service applicatif
↓
Charge un Product via Repository
↓
Product applique les règles métier
↓
Résultat valide
↓
Write Service / Repository de persistance
↓
Stockage
Le Repository abstrait l'accès aux objets métier. Le Write Service contrôle la mutation persistante. L'Aggregate, lui, protège la cohérence métier.
Signaux d'alerte¶
Une modification mérite une revue si elle :
- change directement une variante sans passer par les règles Product ;
- modifie l'identité via SQL ;
- transforme automatiquement une observation en vérité canonique ;
- supprime un conflit pour faciliter l'affichage ;
- fait dépendre Product de WordPress ou d'un feed marchand précis.
Comment diagnostiquer une incohérence Product¶
- Identifier le
Productconcerné. - Vérifier son identité canonique.
- Examiner ses variantes.
- Examiner les observations et identifiants qui servent de preuves.
- Vérifier les conflits explicites.
- Retrouver l'opération qui a produit la dernière modification.
- Corriger la règle ou le chemin d'écriture responsable, puis reconstruire les données dérivées si nécessaire.
Décision d'architecture¶
Décision : CERTIFIED.
Product est l'Aggregate Root explicite du domaine Product. Il protège l'identité et la cohérence métier ; il ne devient ni une couche de persistance ni un orchestrateur Runtime.