Aller au contenu

Conformité DDD — modules Auth (référence) et Notifications (écarts)

Contexte

Rapports d'audit de conformité DDD de PsychoEnLigne (avril 2026) : refactorisation complète du module Auth pour servir de référence, puis audit du module Notifications révélant des écarts par rapport à cette référence.

Contenu

Module Auth — refactorisation de référence (2026-04-20)

Entièrement refactorisé pour conformité DDD stricte : - Schémas Zod déplacés de interface-adapters/validators/ vers infrastructure/schemas/zod/ (convention correcte). - authValidation.ts renommé en ServiceValidationAuth.ts. - Pattern use case 5 étapes harmonisé partout (validation → logique → audit try/catch séparé non-bloquant → construction résultat → gestion erreurs). - Toutes les exceptions extends ErreurMetier avec name + captureStackTrace.

Ce module devient le modèle de référence pour la refactorisation de tous les autres modules du backend (Utilisateurs ensuite, prévu en suite directe).

Module Notifications — écarts trouvés par rapport à la référence

Structure DDD globalement respectée (dossiers, exceptions, service de validation, controller wrapper, module DI), mais violations critiques dans EnvoyerNotificationUseCase :

  • Pattern 5 étapes non respecté — audit fait via .catch() sur la promesse au lieu d'un bloc try/catch privé séparé.
  • construireResultat() retourne un objet simple, sans appeler versObjetPlainPublic() sur une entité — même antipattern que celui trouvé plus tard sur ProjetESM (voir ProjetESM/debug/conformite-modules-backend, violation Règle 14).
  • Méthode parasite traiterNotificationInApp() dans le use case — mélange orchestration et logique d'exécution.
  • Schémas Zod définis directement dans ServiceValidationNotifications.ts au lieu de fichiers séparés dans infrastructure/schemas/zod/.

Frontend — roadmap fonctionnalités (2026-04-22)

Document de planification des fonctionnalités frontend par domaine métier (architecture "Domain-First") : Patients (CRUD, recherche, historique médical), Rendez-vous (calendrier, créneaux, rappels), Consultations (dossier de consultation, ordonnances, prescriptions) — chacun avec ses pages dédiées à développer.

Décision / Conclusion

Le pattern "construireResultat() retourne le DTO brut au lieu d'appeler versObjetPlainPublic() sur l'entité" est un antipattern récurrent à travers plusieurs projets du même auteur (PsychoEnLigne Notifications ici, ProjetESM Enfants plus tard) — signe qu'il vaudrait la peine d'ajouter une vérification automatisée (lint custom ou test d'archi) plutôt que de le détecter module par module à chaque audit manuel.

Liens connexes