portail.eclaireurs-evangeliques.fr : Refactoriser toute l'application en DDD

Cette application grandit petit à petit et prend de plus en plus de responsabilités :

• Gestion des redirections asso-eef.fr
• Création des comptes SharePoint
• Édition des badges EEF depuis un export Assoconnect
• Lien entre les fiches des responsables et les comptes SharePoint
• Gestion des "groupes" avec leurs membres, mailing-listes OVH et droits SharePoint
• WIP dans !43 : gérer les mailing-listes sud-ouest2.org
• WIP dans !18 : auto-valider la création de comptes sur le GK et remplacer inscription.keweenaw.eclaireurs-evangeliques.fr
• WIP dans !44 : consolider les données dans Assoconnect via API
• futur : servir de portail SSO pour Assoconnect et nos autres services tiers, et remplacer AzureAD
• futur potentiel : supervision des référentiels de formation
• futur potentiel : une application de répartition des postes d'action pour un camp

Le code pour toutes ces fonctionnalités est actuellement mélangé selon la structure classique de Laravel, par type de fichier. Cela rend difficile la distinction entre les fonctionnalités qui sont construites ensemble et celles qui sont indépendantes.

Pour rendre l'application plus maintenable et extensible, il est prévu de réorganiser le code en suivant la logique du regroupement par “domaine métier”, comme décrit par exemple dans https://stitcher.io/blog/organise-by-domain.

Cette architecture semble particulièrement convenir car les objectifs de l'application sont des domaines bien distincts et parfois entièrement étanches les uns des autres (redirection et fabrication des badges) et parfois seulement légèrement couplés (par ex gestion des comptes GK et liste des membres dans Assoconnect).

On peut envisager de supprimer le travail fait dans 2c0f9117 pour rendre la base de code plus habituelle selon Laravel, mais ça n'est pas forcément souhaitable.

Cela peut être l'occasion d'intégrer des tests unitaires ou fonctionnels dans l'application, qui en est actuellement dépourvue.