Aller au contenu

Conformité et migration DDD du FrontEnd

Contexte

Audit du 2026-06-16 comparant le frontend React à la référence 2_REFERENCE_FRONTEND_FINAL.md et à ProjetESM/architecture/architecture-fonctionnelle, suivi d'une roadmap de migration en 4 phases.

Contenu

Constat initial (2026-06-16)

Seul le module auth était 100% conforme DDD 4 couches (domain/application/infrastructure/presentation) — utilisé depuis comme module de référence à dupliquer. ThemeProvider, Tailwind config et ApiClient également conformes.

10 modules en structure plate (pas de DDD) : enfants, accompagnements, tuteurs, maitresCoraniques, formations, evaluations, administration, rapports, referentiels, tableau-de-bord — hooks appelant directement les fonctions API au lieu de container.useCase.execute(), stores Zustand non persistants, types mal placés.

Sidebar non conforme : menu plat sans accordéon, RBAC à seulement 2 niveaux (seul ADMIN filtré) au lieu de 3 (Agent/Coordinateur/Admin), sections entières manquantes (Insertion, Mobilisation, Sécurité & Audit).

5 modules métier absents côté frontend malgré leur existence backend : Parents, Insertion socio-éco, Mobilisation communautaire, Audit applicatif ; Sensibilisation et Pilotage partiels seulement.

Roadmap de migration (4 phases) — état constaté le 2026-06-17

Phase 1 — Corrections structurelles : ✅ terminée (sidebar 9 sections + RBAC 3 niveaux, refactoring ThemeProvider.applyTheme() en camelToKebab() générique).

Phase 2 — Migration DDD des modules existants : 5/10 terminés en une journée (enfants, accompagnements, tuteurs, maitresCoraniques, evaluations) — tous suivant strictement le pattern du module auth. Referentiels en cours ; tableau-de-bord, administration, rapports, formations restants.

Phase 3 — Nouveaux modules : mobilisationCommunautaire, pilotage et audit tous terminés le même jour (2026-06-17, mission 20260617_0853) — rattrapage rapide des 3 modules qui n'existaient pas du tout côté frontend. Parents et insertionSocioEconomique restants.

Phase 4 — Qualité & tests : entièrement à faire (Vitest use cases, @testing-library/react composants, Playwright E2E).

Décision / Conclusion

Convention confirmée : méthode use case frontend = execute() (anglais), contre executer() côté backend (français) — distinction volontaire à ne jamais confondre. Le module auth reste la référence structurelle pour toute nouvelle migration DDD frontend du projet.

Liens connexes