Aller au contenu principal

ADR-001 — Monolithe Laravel API central

Statut​

Accepted

Date​

2026-05-10

Contexte​

Faits visibles et contexte validé :

  • le workspace contient un dossier api basé sur Laravel ;
  • l’API expose des routes sous /api/v1 ;
  • le backend contient des modules métier visibles : Identity, Territory, Actor, Publication, Community, Monetization, Settings, Analytics, PlayLoop, AssoSuite, Chat, Mairie et Admin ;
  • l’écosystème DMV cible plusieurs interfaces : DMV public, backoffice, PlayLoop, AssoSuite, Mairie et futures applications connectées ;
  • le projet doit éviter une dispersion de la logique métier dans les frontends.

Objectif :

  • disposer d’une couche métier commune, cohérente et contrôlée pour l’ensemble de l’écosystème.

Décision​

DMV retient une API Laravel centrale, organisée comme un monolithe modulaire.

Cette API sert de socle métier commun pour :

  • DMV ;
  • le backoffice ;
  • PlayLoop ;
  • AssoSuite ;
  • Mairie ;
  • les futures applications connectées.

Les applications gardent leur autonomie côté interface et expérience utilisateur, mais consomment les capacités métier via l’API.

Conséquences​

Effets attendus :

  • mutualisation des règles métier ;
  • cohérence des droits, données et workflows ;
  • réduction des duplications entre applications ;
  • déploiement plus simple qu’un système microservices prématuré ;
  • meilleure lisibilité pour une petite équipe.

Contraintes :

  • le découpage par modules doit rester strict ;
  • les dépendances internes doivent rester maîtrisées ;
  • les services partagés ne doivent pas devenir un bloc difficile à faire évoluer.

Alternatives envisagées​

AlternativeRaison de non-priorisation
Microservices par applicationTrop coûteux et complexe pour l’état actuel du projet.
Backends séparés par appRisque fort de duplication métier et de divergence des règles.
Logique métier majoritairement frontendIncompatible avec la sécurité, le RBAC, les paiements et la cohérence multi-apps.

Risques​

  • Couplage excessif entre modules si les frontières ne sont pas respectées.
  • Croissance du monolithe sans discipline d’architecture.
  • Tentation de créer des exceptions métier par application.

Liens associés​

  • docs/06-architecture/01-global-architecture.md
  • docs/06-architecture/02-monolith-strategy.md
  • docs/07-backend/01-laravel-architecture.md