UC-09 · Afficher un aggregate ne couple pas à sa structure interne
Signal
- Un assembler, un presenter ou un mapper de réponse qui descend loin dans un aggregate (
wallet.blocks[0].directions.debits) et dépend de sa structure interne. - Un aggregate qui expose ses collections internes ou ses parties pour permettre l’affichage.
- Un getter ajouté sur une partie interne à chaque nouvel écran.
Pourquoi
Une view a souvent besoin de plus de données que la tâche elle-même, venues de plusieurs aggregates. L’aggregate doit donc laisser lire son état sans révéler sa forme. Un client qui descend loin à l’intérieur se couple à une implémentation de l’aggregate.
Deux réponses : des méthodes de lecture sur la racine, ou un mediator. Avec un mediator, le client passe un objet qui implémente une interface TypeScript prévue pour cela, et l’aggregate y publie l’état demandé (double dispatch). Cette interface reste centrée sur l’état de l’aggregate, pas sur un écran.
Exceptions
Le mediator fait débat : certains le jugent hors du rôle d’un aggregate, d’autres le trouvent naturel. À décider en équipe.
Avec des queries sur des views (UC-08), un écran ne lit jamais l’aggregate.
Correction
Pour un écran, une query qui lit une view (UC-08, REP-11) : l’aggregate n’est pas lu du tout. Pour le code qui doit lire un aggregate, une méthode de lecture sur la racine qui renvoie des valeurs, ou une interface de mediator.
Adaptation
En TypeScript, un getter qui renvoie une copie en lecture seule (ReadonlyArray, value objects) protège les parties des modifications. Il ne retire pas le couplage à la structure.
Voir aussi
AGG-02 (les parties ne changent que par la racine), REP-11 (une query dédiée qui renvoie une valeur).