Règles Laravel

Statut

Document de règles projet — version initiale.

Objectif

Garantir un backend Laravel modulaire, lisible, maintenable et responsable de la logique métier DMV.

Règles strictes

• La logique métier sensible doit rester côté backend.
• Les contrôleurs doivent rester fins.
• Les entrées HTTP doivent être validées par Form Requests quand pertinent.
• Les autorisations doivent être vérifiées côté backend.
• Ne pas exposer les champs internes ou secrets dans les réponses.
• Ne pas dupliquer une logique de service dans plusieurs modules.
• Ne pas accéder à l'IA directement depuis un contrôleur métier sensible.

Organisation cible

Élément	Rôle
Controller	Entrée HTTP, délégation, réponse.
Request	Validation des payloads.
Service	Logique métier.
Policy / Middleware	Autorisation et périmètre.
DTO / Resource	Sortie structurée.
Job	Traitement asynchrone.
Provider	Enregistrement du module.

Conventions

• Utiliser declare(strict_types=1) dans les nouveaux fichiers PHP.
• Garder les namespaces alignés sur les chemins.
• Nommer les services par domaine : ReadService, WriteService, service spécialisé.
• Filtrer explicitement les champs modifiables.
• Utiliser les jobs pour emails, médias, IA, statistiques et notifications longues.
• Prévoir des tests sur les règles sensibles.

Modules métier

Chaque module doit avoir une responsabilité claire :

• Identity pour profils et rôles ;
• Actor pour acteurs et claims ;
• Publication pour contenus et modération ;
• Mairie, AssoSuite, PlayLoop pour apps métier ;
• Monetization pour paiements et boosts ;
• Admin pour supervision globale.

Anti-patterns

• Contrôleur contenant toute la logique.
• Validation manuelle dispersée.
• Autorisation uniquement frontend.
• Accès direct à DB sans justification dans une logique réutilisable.
• Service générique trop large.
• Mutation silencieuse de champs sensibles.

État actuel vs cible

Sujet	État actuel	Cible
Laravel	Modules visibles et providers.	Architecture modulaire stable.
Services	Présents dans plusieurs domaines.	Convention généralisée.
Supabase	Présence historique.	Rôle rationalisé.

Points à clarifier

• Convention DTO vs API Resources.
• Niveau de tests obligatoire.
• Actions et Events si ajoutés.
• Standard officiel Pint/CI.