Stratégie monolithe Laravel modulaire
Statut
Document de cadrage architecture — version initiale.
Position
La cible DMV privilégie un monolithe Laravel modulaire plutôt qu'une architecture microservices prématurée.
Ce choix permet de centraliser les règles métier, réduire la complexité opérationnelle et accélérer les évolutions tout en gardant des frontières claires entre domaines.
Pourquoi un monolithe modulaire
- Le produit doit commencer simple et rester maintenable.
- Les domaines partagent beaucoup de données : utilisateurs, acteurs, communes, publications, droits.
- Les équipes et usages ne justifient pas encore une multiplication de services indépendants.
- Laravel fournit un cadre solide pour API, jobs, scheduler, tests, policies et services.
- Les modules peuvent évoluer sans être déployés comme microservices séparés.
Modules visibles
Le fichier api/bootstrap/providers.php enregistre notamment :
Identity;Territory;Actor;Publication;Community;Monetization;Settings;Analytics;PlayLoop;AssoSuite;Chat;Mairie;Admin.
Frontières attendues
Chaque module doit porter :
- ses contrôleurs ;
- ses routes ;
- ses modèles ;
- ses DTOs ou formats de sortie ;
- ses requests de validation ;
- ses policies ou règles d'accès ;
- ses services métier ;
- ses jobs éventuels.
Ce que le monolithe ne doit pas devenir
- Un dossier unique sans frontières métier.
- Un ensemble de dépendances circulaires entre modules.
- Une API où les contrôleurs portent toute la logique.
- Un point d'accès direct à toutes les données depuis les frontends.
- Un prétexte pour ignorer tests, contrats et gouvernance.
État actuel vs cible
| Sujet | État actuel visible | Vision cible |
|---|---|---|
| Modules | Structure modulaire déjà présente dans api/app/Modules. | Frontières documentées par domaine. |
| Providers | Modules actifs déclarés dans bootstrap/providers.php. | Chargement maîtrisé et cohérent. |
| Services | Services présents dans plusieurs modules. | Logique métier portée par services, pas par contrôleurs. |
| Jobs | Jobs visibles pour boosts et alertes. | Jobs généralisés pour traitements asynchrones. |
| IA | Pas de module IA confirmé. | AI Gateway comme module ou service transverse. |
Évolution possible
Le monolithe peut évoluer progressivement :
- mieux formaliser les contrats internes ;
- isoler certains workloads via queues ;
- externaliser des services seulement si un besoin réel apparaît ;
- garder les interfaces applicatives découplées de l'implémentation métier.
La séparation en microservices ne doit être envisagée que pour un problème concret : charge, indépendance d'équipe, sécurité, scalabilité ou cycle de déploiement.