Aller au contenu principal

RFC-002 --- Convergence vers un Authorization Platform Service

Statut​

Draft

Auteur​

Architecture DMV

ADR de référence​

  • ADR-014 --- Bounded Contexts and Modular Monolith

Résumé

Centraliser les mécanismes d'autorisation de la plateforme tout en laissant chaque Bounded Context propriétaire de ses règles métier.

1. Problème

Aujourd'hui les contrôles d'accès sont dispersés :

  • politiques dupliquées ;
  • vérifications répétées ;
  • dépendances croisées ;
  • logique métier mélangée avec la sécurité.

Cette situation augmente le risque d'incohérences.

2. Contexte

Chaque Bounded Context connaît ses propres règles métier.

En revanche, les mécanismes techniques (permissions, rôles, vérification, résolution des droits) sont transverses.

Ils relèvent d'un Platform Service.

3. Objectifs

  • supprimer les duplications ;
  • séparer métier et mécanismes techniques ;
  • rendre les règles cohérentes sur toute la plateforme ;
  • préparer les futurs produits (MairieSuite, AssoSuite, Coach, etc.).

4. Hors périmètre

  • authentification ;
  • gestion des utilisateurs ;
  • interface Workspace ;
  • refonte UX.

5. Décision

Création d'un Authorization Platform Service.

Chaque contexte :

  • expose ses politiques ;
  • reste propriétaire des décisions métier.

Authorization :

  • applique ces politiques ;
  • résout les permissions ;
  • fournit une API commune.

Il ne décide jamais de la logique métier.

6. Alternatives étudiées

Autorisation propre à chaque module​

Rejetée.

Elle conduit à la duplication et à des divergences.

Contexte Authorization complet​

Rejeté.

L'autorisation n'est pas un métier mais une capacité technique.

7. Impact

Les contrôles deviennent homogènes.

Les nouveaux produits réutilisent immédiatement les mêmes mécanismes.

8. Plan de migration

Étape 1​

Inventorier toutes les politiques existantes.

Étape 2​

Créer le Platform Service.

Étape 3​

Migrer progressivement les appels.

Étape 4​

Supprimer les implémentations dupliquées.

9. Rollback

Chaque migration est indépendante.

Le retour consiste à réactiver les contrôles précédents pour le module concerné.

10. Critères de succès

  • une seule implémentation des mécanismes d'autorisation ;
  • aucune duplication des contrôles techniques ;
  • les règles métier restent dans leur Bounded Context ;
  • aucun impact fonctionnel pour les utilisateurs.

11. Risques

  • oublier des contrôles existants ;
  • déplacer accidentellement une règle métier dans le Platform Service.

12. Questions ouvertes

  • Modèle exact des permissions.
  • Convention de nommage.
  • Cache éventuel des permissions.

Historique

Date Auteur Modification

2026-07 Architecture DMV Création