Aller au contenu

Rapport d'Analyse de Conformité DDD - Module Notifications

1. État Global

Le module Notifications suit globalement la structure DDD demandée, mais présente plusieurs écarts critiques par rapport aux "Règles Absolues" du GUIDE_ARCHITECTURE_DDD.md.

2. Analyse Détaillée

✅ Points de Conformité

  • Structure des dossiers : Respectée (domain, application, infrastructure, interface-adapters).
  • Exceptions : ErreurNotification hérite bien de ErreurMetier, avec this.name et captureStackTrace.
  • Service de Validation : Implémentation correcte avec Map de schémas Zod et structure à deux étapes.
  • Controller Wrapper : NotificationsModuleController utilise des arrow functions et gère correctement req.utilisateur.
  • DI Module : Structure correcte et respect des interfaces.

❌ Non-Conformités et Écarts (Critiques)

A. Use Cases (Sévérité : Haute)

Dans EnvoyerNotificationUseCase.ts : - Violation de la règle des 5 étapes : Le Use Case ne respecte pas strictement le squelette obligatoire. - Audit bloquant : L'audit est fait via .catch() sur la promesse, mais la structure recommandée est un bloc try/catch privé séparé. - Construction du résultat : construireResultat() retourne un objet simple au lieu d'appeler versObjetPlainPublic() sur une entité. - Logique métier : executerLogique() appelle un service externe (notificationService) mais ne manipule pas d'entité métier pour valider des invariants avant l'envoi. - Méthode parasite : Présence de traiterNotificationInApp() dans le Use Case, ce qui mélange orchestration et logique d'exécution.

B. Domaine & Entités (Sévérité : Moyenne)

  • Invariants : L'entité Notification (à vérifier plus en détail) semble être utilisée comme un simple DTO dans le use case traiterNotificationInApp.

C. Infrastructure (Sévérité : Faible)

  • Schémas Zod : Les schémas sont définis directement dans le ServiceValidationNotifications.ts au lieu d'être dans des fichiers séparés dans infrastructure/schemas/zod/.

3. Recommandations

  1. Refactoriser EnvoyerNotificationUseCase :
  2. Réimplémenter strictement les 5 étapes : Validation $\rightarrow$ Logique $\rightarrow$ Audit $\rightarrow$ Construction $\rightarrow$ Gestion Erreur.
  3. Déplacer la logique de traiterNotificationInApp vers un service de domaine ou l'intégrer correctement dans executerLogique.

  4. Utiliser versObjetPlainPublic() pour le résultat final.

  5. Déplacer les schémas Zod :

  6. Créer des fichiers individuels dans infrastructure/schemas/zod/ pour chaque action (ex: envoyerNotification.schemas.ts).

  7. Renforcer l'Entité Notification :

  8. S'assurer que Notification.creer() valide les invariants métier et que l'entité possède des comportements propres.