Aller au contenu principal

RFC-004 — Actor Claims Workflow

Statut​

Draft

Auteur​

Architecture DMV

ADR de référence​

  • ADR-014 — DMV Core : Bounded Contexts and Modular Monolith

Résumé

Structurer le processus de revendication d'un acteur sans créer un Bounded Context autonome Claims.

La revendication reste une capacité du Bounded Context Actor. Les étapes longues, asynchrones ou impliquant plusieurs contextes sont coordonnées par un Process Manager explicite.

1. Problème

Le processus de revendication d'un acteur implique plusieurs responsabilités :

  • identifier l'acteur concerné ;
  • vérifier l'identité du demandeur ;
  • collecter des justificatifs ;
  • contrôler son droit à administrer l'acteur ;
  • accepter ou refuser la demande ;
  • créer la relation d'administration ;
  • notifier le demandeur ;
  • conserver une trace de la décision.

Dans l'architecture actuelle, ces responsabilités peuvent être dispersées entre :

  • Actor ;
  • Identity ;
  • Authorization ;
  • Admin ;
  • Workspace ;
  • notifications ;
  • logique applicative ad hoc.

Cette dispersion favorise :

  • les écritures croisées ;
  • la duplication des contrôles ;
  • les états incohérents ;
  • les workflows difficiles à reprendre après une erreur ;
  • une confusion sur le propriétaire de la décision.

2. Contexte

Une revendication vise à obtenir le droit d'administrer un acteur DMV existant.

L'objet revendiqué appartient au Bounded Context Actor.

La décision finale consiste à modifier la relation entre :

  • un utilisateur ;
  • un acteur ;
  • un rôle ou niveau d'administration.

Le workflow peut toutefois nécessiter des informations ou services externes à Actor, notamment :

  • identité du demandeur ;
  • mécanismes d'autorisation ;
  • examen humain dans le Backoffice ;
  • stockage de justificatifs ;
  • notifications.

Cette orchestration ne justifie pas la création d'un Bounded Context Claims.

3. Objectifs

  • faire de Actor le propriétaire clair des revendications ;
  • centraliser l'état du workflow ;
  • empêcher les écritures directes dans plusieurs contextes ;
  • rendre le processus traçable, reprenable et idempotent ;
  • séparer décision métier, orchestration et mécanismes techniques ;
  • préparer les futures revendications d'associations, commerces, mairies et autres organisations.

4. Hors périmètre

Cette RFC ne définit pas :

  • l'interface exacte du formulaire de revendication ;
  • la liste définitive des justificatifs ;
  • les règles commerciales associées aux offres payantes ;
  • le détail de l'authentification ;
  • l'implémentation technique du moteur de workflow ;
  • la modération générale des contenus ;
  • les processus propres à AssoSuite ou MairieSuite.

5. Décision

5.1 Ownership​

Le Bounded Context Actor possède :

  • la demande de revendication ;
  • son statut ;
  • son historique métier ;
  • les justificatifs référencés ;
  • la décision d'accepter ou de refuser ;
  • la relation finale entre l'utilisateur et l'acteur.

Claims ne devient pas un Bounded Context autonome.

5.2 Process Manager​

Un Actor Claim Process Manager coordonne le workflow lorsqu'il implique plusieurs étapes ou services.

Il peut notamment :

  1. enregistrer la demande dans Actor ;
  2. demander la vérification de l'identité ;
  3. attendre les justificatifs requis ;
  4. transmettre la demande à un opérateur lorsque nécessaire ;
  5. recevoir la décision ;
  6. demander à Actor d'accorder ou de refuser la revendication ;
  7. déclencher les notifications correspondantes.

Le Process Manager :

  • ne devient pas propriétaire des données métier ;
  • ne modifie pas directement les tables d'autres contextes ;
  • conserve uniquement l'état d'orchestration nécessaire ;
  • utilise des commandes, contrats publiés et événements métier.

5.3 États métier​

Le modèle cible doit permettre au minimum les états suivants :

Draft
Submitted
PendingVerification
PendingReview
Approved
Rejected
Cancelled
Expired

Les transitions doivent être explicites et contrôlées par Actor.

Exemples :

Draft -> Submitted
Submitted -> PendingVerification
PendingVerification -> PendingReview
PendingReview -> Approved
PendingReview -> Rejected
Submitted -> Cancelled
PendingVerification -> Expired

Une transition invalide doit être refusée.

5.4 Commandes​

Exemples de commandes publiées par Actor :

StartActorClaim
SubmitActorClaim
AttachClaimEvidence
RequestClaimReview
ApproveActorClaim
RejectActorClaim
CancelActorClaim
ExpireActorClaim

Une commande exprime une intention.

Elle peut être refusée si les invariants ne sont pas respectés.

5.5 Événements métier​

Exemples :

ActorClaimStarted
ActorClaimSubmitted
ActorClaimEvidenceAttached
ActorClaimVerificationRequested
ActorClaimReviewRequested
ActorClaimApproved
ActorClaimRejected
ActorClaimCancelled
ActorClaimExpired
ActorAdministratorGranted

Les événements :

  • sont immuables ;
  • décrivent des faits passés ;
  • sont versionnés ;
  • ne deviennent pas automatiquement la source de vérité ;
  • peuvent alimenter notifications, audit, analytics et projections.

5.6 Autorisation​

Actor définit les règles métier, par exemple :

  • qui peut initier une revendication ;
  • dans quels cas une revendication est possible ;
  • qui peut approuver ou refuser ;
  • si plusieurs administrateurs peuvent coexister ;
  • comment traiter un acteur déjà revendiqué.

Le Authorization Platform Service fournit les mécanismes nécessaires pour appliquer ces décisions, sans les posséder.

5.7 Backoffice​

Le Backoffice est une application d'administration.

Il ne possède pas le workflow.

Il utilise les contrats publiés par Actor pour :

  • consulter les demandes ;
  • examiner les justificatifs ;
  • approuver ;
  • refuser ;
  • ajouter une justification interne.

Aucune décision métier ne doit être implémentée exclusivement dans l'interface Backoffice.

5.8 Justificatifs et données sensibles​

Les justificatifs doivent être :

  • stockés hors des tables métier principales ;
  • accessibles uniquement aux rôles autorisés ;
  • référencés depuis la revendication ;
  • soumis à une durée de conservation définie ;
  • supprimables indépendamment de l'historique métier lorsque la réglementation l'exige.

La revendication conserve la trace de la décision sans imposer la conservation permanente des documents fournis.

6. Alternatives étudiées

6.1 Créer un Bounded Context Claims​

Rejeté.

La revendication n'a pas de modèle métier autonome suffisant. Elle concerne directement la propriété et l'administration d'un acteur.

Créer un contexte séparé fragmenterait l'ownership et imposerait une coordination permanente avec Actor.

6.2 Implémenter le workflow dans le Backoffice​

Rejeté.

Le Backoffice est une application, pas le propriétaire du métier.

Cette option rendrait la décision dépendante de l'interface et compliquerait les futurs canaux.

6.3 Modifier directement les relations utilisateur-acteur​

Rejeté.

Cette approche ne fournit ni état intermédiaire, ni historique, ni reprise, ni contrôle explicite des transitions.

7. Impact

Actor​

Devient le propriétaire unique des demandes de revendication et des décisions associées.

Identity​

Fournit l'identité authentifiée et, si nécessaire, des résultats de vérification via un contrat publié.

Authorization​

Applique les politiques exposées par Actor.

Backoffice​

Devient un client du workflow, sans accès direct aux tables métier.

Workspace​

Peut initier et suivre une revendication via les contrats d'Actor.

Notifications​

Consomme les événements de revendication sans intervenir dans la décision.

8. Plan de migration

Étape 1 — Inventaire​

Identifier :

  • les routes existantes ;
  • les services ;
  • les tables ;
  • les statuts ;
  • les écritures directes ;
  • les vérifications d'autorisation ;
  • les notifications ;
  • les interfaces Backoffice et Workspace concernées.

Étape 2 — Modèle métier cible​

Créer dans Actor :

  • l'entité ou agrégat de revendication ;
  • les statuts ;
  • les transitions ;
  • les invariants ;
  • les commandes ;
  • les événements.

Aucun changement fonctionnel visible n'est requis à cette étape.

Étape 3 — Contrats applicatifs​

Créer les cas d'usage publiés nécessaires :

StartActorClaim
GetActorClaim
ListActorClaims
SubmitActorClaim
ApproveActorClaim
RejectActorClaim
CancelActorClaim

Étape 4 — Process Manager​

Introduire l'Actor Claim Process Manager pour coordonner :

  • vérification ;
  • revue humaine ;
  • décision ;
  • attribution des droits ;
  • notifications.

Étape 5 — Migration des interfaces​

Faire migrer progressivement :

  • Workspace ;
  • Backoffice ;
  • API publiques ou privées concernées.

Les interfaces ne doivent plus écrire directement dans les tables de revendication ou de collaboration.

Étape 6 — Suppression du legacy​

Supprimer :

  • les services dupliqués ;
  • les transitions implicites ;
  • les écritures croisées ;
  • les contrôles uniquement présents dans les contrôleurs ;
  • les accès directs aux modèles d'un autre contexte.

9. Rollback

La migration est réalisée par étapes.

Chaque interface peut temporairement revenir à son ancien chemin tant que :

  • le modèle historique est maintenu ;
  • les données restent synchronisées de manière contrôlée ;
  • aucune double décision n'est possible.

Aucune étape ne doit supprimer l'ancien mécanisme avant validation du nouveau parcours complet.

10. Critères de succès

La RFC est terminée lorsque :

  • Actor possède toutes les revendications ;
  • aucun Bounded Context Claims autonome n'existe ;
  • toutes les transitions sont explicites ;
  • les interfaces utilisent des contrats publiés ;
  • aucune écriture croisée ne subsiste ;
  • le workflow est reprenable après erreur ;
  • les consommateurs sont idempotents ;
  • l'approbation crée la relation utilisateur-acteur attendue ;
  • le refus, l'annulation et l'expiration sont tracés ;
  • les justificatifs respectent les règles d'accès et de conservation ;
  • les notifications sont déclenchées par événements.

11. Risques

  • reproduire des règles métier dans le Process Manager ;
  • créer un workflow trop générique et difficile à maintenir ;
  • autoriser deux décisions concurrentes ;
  • conserver indéfiniment des justificatifs sensibles ;
  • dupliquer les statuts entre Actor, Backoffice et Workspace ;
  • rendre l'approbation non idempotente ;
  • mélanger revendication d'acteur et invitation d'un collaborateur.

12. Questions ouvertes

  • Quels justificatifs sont requis selon le type d'acteur ?
  • Une revendication peut-elle être entièrement automatique dans certains cas ?
  • Comment traiter un acteur déjà administré ?
  • Quelle durée d'expiration appliquer aux demandes incomplètes ?
  • Quelle durée de conservation appliquer aux justificatifs ?
  • Faut-il permettre un recours après rejet ?
  • Quelles différences entre revendication initiale et transfert d'administration ?
  • Le processus municipal nécessite-t-il une validation renforcée ?

Historique

DateAuteurModification
2026-07-22Architecture DMVCréation de la RFC