Séparation des activités du BC Administrative dans un nouveau BC
Créer un nouveau BC Activities qui permettra de :
- alléger le BC Administrative dont les frontières ont été mal définies au départ,
- utiliser les projections phpep,
- préfixer toutes les routes par
/activities
.
Réécriture des évènements
Les évènements de mise à jour des informations doivent être ré-écris : dans le BC Administrative il y avait un unique évènement ActivityUpdated
avec tous les champs dedans, il ne faut pas faire ça car :
- ça enlève une certaine flexibilité (besoin de faire attention à plein de choses quand on veut le modifier),
- on ne peut pas effacer un champ car impossible de savoir dans l'évènement si le champ est mis à
null
ou non mis à jour.
À la place, faire un évènement pour chaque modification de champ (NameChanged
, ApeCodeChanged
, ...).
Profiter de cette réécriture pour supprimer les champs :
-
natures
qui n'est ni affiché ni utile (les natures se calculent à partir des métiers) -
websiteLocations
qui n'est pas non plus affiché
Spécificité phpep
Étant donné que les évènements actuels ne sont pas gérés avec phpep, il faudra créer un StreamFactory
qui produise les nouveaux évènements à partir des anciens. De cette façon la projection des activités pourra être construite avec les anciens évènements et les nouveaux.
Dans un second temps, on pourra lancer la projection des évènements eux-mêmes (activity_events
) pour transformer les anciens évènements en nouveaux et pouvoir supprimer les anciens, puis supprimer l'ancien code dans Administrative (dans la MR supplémentaire).
Impacts dans le reste de l'application
Bien penser à modifier le ActivityEventSubscriber
du BC ExtendedMembers et ce qui va avec.
Frontend
Faire en sorte que le front continue de fonctionner en faisant les modifications nécessaires (si besoin) pour s'adapter aux nouveau BC (notamment le changement des endpoints) :
- onglet activité de la fiche du membre,
- création d'un nouveau membre,
- création d'un nouveau contrat (étape "vérification des informations" avant la création d'un contrat)
Avec #360, les deux dernières parties n'existeront plus donc pas besoin d'aller plus loin que juste quelque chose qui fonctionne.