[CLEANUP] Utilisation d'un read-model dans le service Current-user de Pix Orga (PIX-553).

[chrc]

🦄 Problème

Depuis le front, dans le service current-user de Pix Orga, trois requêtes distinctes sont réalisées pour récupérer l'utilisateur connecté (tous ses attributs), ses memberships ainsi que ses paramètres (userOrgaSettings).
S'enchainent des opérations difficilement lisibles, qui pourraient être effectuées par l'API.

Seuls les attributs du user firstName, lastName et pixOrgaTermsOfServiceAccepted sont utilisés.
La récupération des memberships et de userOrgaSettings s'effectue en deux appels vers l'API (cf. api/lib/infrastructure/serializers/jsonapi/user-serializer.js).

🤖 Solution

• Introduction d'un nouveau read-model Prescriber

class Prescriber {
  constructor({
    id,
    // attributes
    firstName,
    lastName,
    pixOrgaTermsOfServiceAccepted,
    // includes
    memberships = [],
    userOrgaSettings,
  } = {}) {...}
}

• Nouveau endpoint api

{
  method: 'GET',
  path: '/api/prescription/prescribers/{userId}',
  config: {
    validate: {
      params: Joi.object({
        userId: Joi.number().required(),
      }),
    },
    pre: [{
      method: securityPreHandlers.checkRequestedUserIsAuthenticatedUser,
      assign: 'requestedUserIsAuthenticatedUser'
    }],
    handler: prescriberController.get,
    notes: [
      '- **Cette route est restreinte aux utilisateurs authentifiés**\n' +
      '- Récupération d’un prescripteur.\n' +
      '- L’id demandé doit correspondre à celui de l’utilisateur authentifié',
    ],
    tags: ['api', 'user', 'prescription'],
  }
}

• Modification des tests e2e pour prendre en compte ce endpoint

🌈 Remarques

• Ceci est un premier refacto
• Dans un deuxième temps, les opérations seront effectuées par l'API

💯 Pour tester

⚠️ Ce connecter à Pix Orga et faire une recette globale des fonctionnalités.

[pix-service]

I'm deploying this PR to these urls:

• App: https://app-pr1448.review.pix.fr
• Orga: https://orga-pr1448.review.pix.fr
• Certif: https://certif-pr1448.review.pix.fr
• Admin: https://admin-pr1448.review.pix.fr
• API: https://api-pr1448.review.pix.fr/api/

Please check it out!

[Giroteti]

Quand on utilise les read-model (dans une logique de flux descendant / query) il n'y a pas de logique "métier" à appliquer, simplement de la logique de récupération de données et de présentation de la données (répo & serializer) et le usecase devient obsolète car il ne fait que passe plat, comme ici.

Tu peux donc t'en passer et appeler le repo directement depuis le controller, comme ce qui est fait ici.

C'est d'ailleurs assez cohérent avec la logique de séparation du read et du write, dans cette logique, seul le write est considérée comme étant du "métier" alors que read est un détail d'implémentation. Le usecase étant un classe d'orchestration de workflow "métier" il est normal qu'on ne l'utilise pas sur le write.

Par ailleurs, même si ce n'est pas ce qu'on a fait jusqu'à maintenant : les read-models ne devraient pas se trouver dans domain, ils font partie de l'infrastructure.

Voir ici : #649 (comment)

[yahyayouness]

Cette PR etant mergé avant tes retours, on le prend en compte dans la prochaine PR de refacto

[Giroteti]

Le prescriber étant un read-model ne devrait pas faire partie du domain.
_toPrescriberDomain -> _toPrescriberReadModel

[yahyayouness]

Idem

[Giroteti]

Membership et Organization semblent ne pas être des read-model.
Il faut soit :

• qu'ils soient des read-models (s'ils ne servent pas dans le domain par ailleurs)
• faire des read-model correspondant

[yahyayouness]

A creuser dans le prochain point design code !