Aller au contenu

Mission : Refactorisation Complète du Module Utilisateurs à 100% de Conformité DDD

Date : 2026-04-21 Heure : 15:57

Objectif

Porter le module Utilisateurs de PsychoEnLigneV2 à 100% de conformité avec les conventions DDD définies dans le GUIDE_ARCHITECTURE_DDD.md et CLAUDE.md, en suivant le même modèle de réussite que le module Auth.

Contexte

Le module Utilisateurs présente des écarts significatifs par rapport aux conventions strictes du projet. Suite à la refactorisation réussie du module Auth (passé de 90% à 100% de conformité), le module Utilisateurs nécessite une intervention complète pour atteindre les mêmes standards.

Analyse Actuelle

D'après l'audit détaillé réalisé, les points critiques à corriger sont :

Écarts Majeurs Identifiés

  1. Nommage du ServiceValidation : utilisateursValidation.ts au lieu de ServiceValidationUtilisateurs.ts
  2. Emplacement des schémas Zod : interface-adapters/validator/zod/ au lieu de infrastructure/schemas/zod/
  3. Structure des dossiers : Organisation non conforme aux standards du GUIDE_ARCHITECTURE_DDD.md
  4. Imports à mettre à jour : Tous les fichiers utilisant les anciens chemins

Conformité Estimée

  • Actuelle : 85%
  • Cible : 100%
  • Écarts critiques : 2 majeurs + restructuration complète

Consignes Générales

  • Suivre STRICTEMENT le GUIDE_ARCHITECTURE_DDD.md situé dans /home/kanmaber/projets/ReadMe/GUIDE_ARCHITECTURE_DDD.md
  • Appliquer les MÊMES STANDARDS que ceux utilisés pour le module Auth
  • Respecter l'architecture en 5 couches par module :
  • domain/ (entités, interfaces, exceptions, schemas, types)
  • application/ (interfaces, usecases)
  • infrastructure/ (di, repositories, schemas/zod, services)
  • interface-adapters/ (controllers, handlers, routes, validators)
  • Appliquer le pattern use case en 5 étapes obligatoires
  • Centraliser les schémas Zod dans infrastructure/schemas/zod/
  • Créer un ServiceValidation par module avec nommage standardisé
  • Assurer que toutes les exceptions héritent de ErreurMetier
  • Mettre en place l'audit dans des try/catch séparés (non bloquant)

Étapes de Refactorisation

Phase 1 : Audit Complet et Inventaire (TERMINÉ)

  1. Cartographie des fichiers : 103 fichiers répartis dans 5 couches
  2. Identification des écarts : 2 écarts majeurs + restructuration
  3. Priorisation des corrections : ServiceValidation + Schémas Zod

Phase 2 : Normalisation du Nommage des Fichiers

  1. ServiceValidation : Renommer utilisateursValidation.ts en ServiceValidationUtilisateurs.ts
  2. Mettre à jour les imports : Dans tous les fichiers utilisant ce service
  3. Vérifier la conformité : S'assurer que tous les use cases utilisent le nouveau nom

Phase 3 : Restructuration des Schémas Zod (CRITIQUE)

  1. Créer la structure cible : infrastructure/schemas/zod/
  2. Déplacer tous les schémas : Depuis interface-adapters/validator/zod/ vers infrastructure/schemas/zod/
  3. Mettre à jour ServiceValidation : Modifier tous les imports des schémas
  4. Mettre à jour les use cases : Corriger tous les imports affectés
  5. Nettoyer l'ancienne structure : Supprimer interface-adapters/validator/

Fichiers à déplacer (17 identifiés) : - assignerPermissions.schemas.ts - basculerActivation.schemas.ts - changerRole.schemas.ts - creerRole.schemas.ts - creerUtilisateur.schemas.ts - exporterUtilisateurs.schemas.ts - listerPermissions.schemas.ts - listerRoles.schemas.ts - listerUtilisateurs.schemas.ts - mettreAJourUtilisateur.schemas.ts - modifierRole.schemas.ts - obtenirRole.schemas.ts - obtenirStatistiques.schemas.ts - obtenirUtilisateur.schemas.ts - supprimerRole.schemas.ts - supprimerUtilisateur.schemas.ts

Phase 4 : Alignement Structure Dossiers

  1. Vérifier la cohérence : Avec le modèle du module Auth
  2. Controllers : Confirmer l'organisation thématique (acceptable si cohérente)
  3. Handlers : S'assurer qu'ils correspondent aux controllers
  4. Routes : Aligner avec le système d'auto-discovery

Phase 5 : Standardisation Controllers/Handlers

  1. Pattern Controller : Vérifier l'implémentation du wrapper pattern
  2. Factory Functions : Standardiser les fonctions de création
  3. Handlers : Vérifier l'implémentation du Template Method Pattern
  4. Module DI : S'assurer que toutes les dépendances sont correctement injectées

Phase 6 : Vérifications et Tests Antipatterns

  1. Compilation TypeScript : npx tsc --noEmit doit retourner 0 erreur
  2. Antipatterns :
  3. Aucun !validation.succes qui retourne au lieu de throw
  4. Aucun audit bloquant (await this.auditer dans try/catch séparé)
  5. Aucune exception qui extends Error au lieu de ErreurMetier
  6. Tests unitaires : S'assurer que tous les tests passent
  7. Intégration : Tester les endpoints API critiques

Livrables Attendus

  1. Module Utilisateurs 100% conforme aux conventions DDD
  2. Aucune erreur de compilation TypeScript
  3. Aucun antipattern identifié par les vérifications obligatoires
  4. Structure des schémas Zod alignée sur infrastructure/schemas/zod/
  5. ServiceValidation correctement nommé
  6. Mise à jour du rapport dans BackEnd/Documents/
  7. Checkpoint de progression dans .claude/missions/

Vérifications Finales Obligatoires

  • npx tsc --noEmit (0 erreur TypeScript)
  • Aucun antipattern de validation (pas de return { succes: false })
  • Aucun audit bloquant (toujours dans try/catch séparé)
  • Aucune exception qui extends Error au lieu de ErreurMetier
  • Tous les noms de fichiers conformes aux conventions
  • Structure de dossiers alignée sur le GUIDE_ARCHITECTURE_DDD.md
  • Schémas Zod dans infrastructure/schemas/zod/ uniquement

Contraintes Techniques

  • Ne jamais copier le code de l'original - extraire les règles métier et les réimplémenter en DDD
  • Respecter les IDs CUIDs (pas de UUIDs)
  • Ne jamais valider avec z.string().uuid()
  • L'audit ne doit jamais bloquer l'opération principale
  • Les schémas Zod doivent être centralisés dans infrastructure/schemas/zod/
  • Un ServiceValidation par module avec nommage standardisé
  • Toutes les exceptions doivent hériter de ErreurMetier
  • Suivre les MÊMES STANDARDS que le module Auth (référence)

Référence de Succès

Utiliser le module Auth comme modèle de référence : - Structure des dossiers identique - Mêmes patterns de nommage - Mêmes implémentations de handlers/controllers - Mêmes vérifications antipatterns - Même qualité de documentation

Points d'Attention Spécifiques

  1. Impact des imports : Le déplacement des schémas affectera de nombreux fichiers
  2. ServiceValidation : Renommage impacte tous les use cases
  3. Tests : S'assurer que les tests sont mis à jour avec les nouveaux chemins
  4. Module DI : Vérifier que l'injection fonctionne avec les nouveaux noms

Critère de Succès

Le module Utilisateurs doit atteindre exactement le même niveau de conformité que le module Auth : 100% DDD compliant avec zéro antipattern et structure parfaitement alignée sur les standards du projet.