Aller au contenu principal

Couche services métier

Statut​

Document de cadrage architecture — version initiale.

Objectif​

La couche services métier porte les règles applicatives de DMV.

Elle doit éviter que les contrôleurs, jobs ou frontends manipulent directement la logique métier complexe. Les services deviennent le point de coordination entre modèles, droits, validations, événements et intégrations.

État actuel visible​

Plusieurs modules Laravel possèdent déjà des dossiers Services, notamment :

  • acteurs ;
  • administration ;
  • analytics ;
  • AssoSuite ;
  • chat ;
  • community ;
  • identity ;
  • mairie ;
  • monetization ;
  • PlayLoop ;
  • publication ;
  • settings ;
  • territory.

Cette structure confirme une base de séparation métier.

Responsabilités d'un service​

Un service métier peut gérer :

  • orchestration d'une action ;
  • lecture ou écriture contrôlée ;
  • vérification métier complémentaire ;
  • appel à d'autres modules autorisés ;
  • préparation d'un DTO ou résultat ;
  • déclenchement de jobs ;
  • intégration avec services externes ;
  • préparation de contexte pour l'AI Gateway cible.

Ce qui ne doit pas être dans le service​

  • Rendu UI.
  • Code spécifique frontend.
  • Secrets exposés.
  • Requêtes non contrôlées contournant les droits.
  • Décisions critiques non testables.

Relation avec les contrôleurs​

Les contrôleurs doivent rester minces :

  • recevoir la requête ;
  • valider via Request ou règles dédiées ;
  • appeler un service ;
  • retourner une réponse structurée.

La logique métier doit être dans les services, policies, actions ou objets dédiés.

Services transverses cibles​

ServiceRôle
NotificationsEmails, push, alertes, messages système.
MediaUpload, transformation, droits, stockage.
AnalyticsTraçage, agrégation, événements.
AI GatewayOrchestration IA et sécurité.
BillingAbonnements, boosts, crédits.
AuthorizationDroits inter-applications et contextes.

Certains éléments existent déjà par modules, mais leur mutualisation complète reste une vision cible.

Risques et points à clarifier​

  • Dépendances entre modules à documenter.
  • Contrats de services à stabiliser.
  • Cas où un service transverse doit être extrait d'un module à définir.
  • Tests métier à renforcer autour des services critiques.