Aller au contenu

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

Date : 2026-04-21 Heure: 12:05

Objectif

Porter le module Auth de PsychoEnLigneV2 à 100% de conformité avec les conventions DDD définies dans le GUIDE_ARCHITECTURE_DDD.md et CLAUDE.md.

Contexte

Le module Auth est fonctionnel mais présente quelques écarts mineurs par rapport aux conventions strictes du projet. Une refactorisation complète est nécessaire pour assurer l'uniformité et la maintenabilité à long terme.

Analyse Actuelle

D'après l'analyse détaillée disponible dans /home/kanmaber/projets/PsychoEnLigneV2/BackEnd/Documents/analyse_module_auth.md, les points à améliorer sont :

  1. Nommage des fichiers : Certains fichiers ne suivent pas exactement les conventions
  2. Emplacement des schémas : Organisation des schémas Zod à restructurer
  3. Structure des dossiers : Quelques différences dans l'organisation des sous-dossiers
  4. Pattern Controller : Alignement avec les conventions du GUIDE_ARCHITECTURE_DDD.md

Consignes Générales

  • Suivre strictement le GUIDE_ARCHITECTURE_DDD.md situé dans /home/kanmaber/projets/ReadMe/GUIDE_ARCHITECTURE_DDD.md
  • 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
  • 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

  1. Cartographie des fichiers : Dresser la liste exhaustive de tous les fichiers du module Auth
  2. Identification des écarts : Répertorier tous les fichiers/conventions non conformes
  3. Priorisation des corrections : Classer les écarts par ordre d'importance

Phase 2 : Normalisation du Nommage

  1. Interfaces Use Cases : Vérifier que tous suivent le pattern I{Action}{Nom}UseCase.ts
  2. Implémentations Use Cases : Vérifier que tous suivent le pattern {Action}{Nom}UseCase.ts
  3. Interfaces Repositories : Vérifier le pattern I{Nom}Repository.ts
  4. Implémentations Repositories : Vérifier le pattern {Nom}RepositoryPrisma.ts
  5. Autres interfaces/services : Aligner sur les conventions de nommage

Phase 3 : Restructuration des Schémas

  1. Constantes Domain : Déplacer toutes les constantes string dans domain/schemas/{nom}.schemas.ts
  2. Schémas Zod : Déplacer toutes les implémentations Zod dans infrastructure/schemas/zod/
  3. Imports : Mettre à jour tous les imports pour utiliser les nouveaux chemins
  4. Validation : S'assurer que tous les schémas sont correctement référencés

Phase 4 : Alignement Structure Dossiers

  1. Domain : Réorganiser selon le modèle référence
  2. Application : Vérifier la cohérence des sous-dossiers
  3. Infrastructure : Aligner la structure avec les conventions
  4. Interface-Adapters : Réorganiser controllers, handlers, routes, validators

Phase 5 : Standardisation Controllers/Handlers

  1. Pattern Controller : Aligner sur le modèle NomModuleController.ts
  2. Factory Functions : Standardiser les fonctions de création
  3. Handlers : Vérifier l'implémentation du Template Method Pattern
  4. Routes : Aligner avec le système d'auto-discovery

Phase 6 : Vérifications et Tests

  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 Auth 100% conforme aux conventions DDD
  2. Aucune erreur de compilation TypeScript
  3. Aucun antipattern identifié par les vérifications obligatoires
  4. Mise à jour du rapport dans BackEnd/Documents/
  5. 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

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
  • Toutes les exceptions doivent hériter de ErreurMetier