Une application métier commence souvent petite : un formulaire, une liste, un export. Deux ans plus tard, elle gère des validations, des rôles, des notifications et des dizaines d’écrans. Ce qui fait la différence entre un projet qui reste agréable à faire évoluer et un projet que plus personne n’ose toucher, ce sont quelques décisions prises très tôt.
Ce qu’il faut retenir
- Des contrôleurs minces : ils reçoivent la requête, délèguent, renvoient une réponse. La logique métier vit ailleurs.
- Des classes d’action (
ApproveRequest,GenerateInvoice) : une classe, une opération métier, facile à tester et à réutiliser depuis un contrôleur, une commande ou une tâche planifiée. - La validation dans des Form Requests, jamais copiée-collée entre contrôleurs.
- Les droits dans des Policies :
$this->authorize('approve', $request)se lit comme une phrase et centralise les règles.
Les états plutôt que des booléens
Un circuit de validation se modélise mal avec is_validated et is_rejected. Une colonne status adossée à un enum PHP (draft, pending, approved, rejected) rend les transitions explicites et évite les combinaisons impossibles.
Les tâches lentes en file d’attente
Génération de PDF, envoi d’e-mails, imports Excel : tout ce qui dépasse une seconde part dans une queue. L’utilisateur garde une interface rapide, et un échec se rejoue sans tout recommencer.
Conseil pratique
Avant d’ajouter une fonctionnalité, écrivez en une phrase l’opération métier qu’elle représente. Si la phrase tient, elle devient une classe d’action. Si elle ne tient pas, le besoin n’est pas encore assez clair pour être codé.
