Aller au contenu principal

RFC-001 --- Extraction du Bounded Context Municipal Management

Statut​

Proposée

Objectif

Extraire le métier municipal du module historique Mairie afin d'obtenir une séparation claire entre :

  • le territoire ;
  • l'organisation municipale ;
  • les opérations municipales.

Cette RFC ne crée pas MairieSuite.

Elle prépare DMV Core à accueillir MairieSuite sans faire de cette future application le propriétaire du métier.

Contexte

L'analyse de l'existant a montré que le module Mairie mélange aujourd'hui plusieurs responsabilités :

  • identité territoriale ;
  • identité organisationnelle de la mairie ;
  • données métier municipales ;
  • opérations municipales ;
  • logique de publication.

Cette situation entraîne :

  • des écritures croisées ;
  • des dépendances directes ;
  • une confusion des responsabilités ;
  • une difficulté d'évolution.

L'ADR-014 interdit désormais cette organisation.

Décision

Le métier municipal devient un Bounded Context autonome :

Municipal Management

Il est propriétaire exclusivement des capacités métier municipales.

Il référence :

  • Territory
  • Actor

sans en devenir propriétaire.

Ownership

Municipal Management possède :

  • élus ;
  • collectes ;
  • informations pratiques ;
  • services municipaux ;
  • alertes municipales ;
  • toutes les futures capacités propres à la gestion municipale.

Il ne possède jamais :

  • la commune ;
  • le code INSEE ;
  • le territoire ;
  • la mairie comme organisation.

Références

Chaque enregistrement municipal référence :

territory_id
actor_id

Le territoire reste indépendant.

La mairie reste un acteur.

Responsabilités

Municipal Management décide :

  • qu'un élu est publié ;
  • qu'une collecte est active ;
  • qu'une information pratique change ;
  • qu'une alerte municipale existe.

Il ne décide pas :

  • de la diffusion publique ;
  • des notifications ;
  • de l'indexation ;
  • des permissions génériques.

Contrats publiés

Exemples :

GetMunicipalServices
GetMunicipalInformations
GetMunicipalOfficials
GetMunicipalCollections
GetMunicipalAlerts

Événements publiés

Exemples :

MunicipalAlertPublished
MunicipalAlertUpdated
MunicipalOfficialUpdated
MunicipalCollectionUpdated
MunicipalInformationUpdated

Ces événements décrivent uniquement des faits municipaux.

Relations

Territory​

Lecture uniquement.

Municipal Management ne modifie jamais le territoire.

Actor​

Lecture uniquement.

Municipal Management ne modifie jamais l'identité de la mairie.

Publication​

Lorsqu'une information municipale devient publique, Municipal Management publie un événement.

Publication décide :

  • comment le contenu est diffusé ;
  • où il apparaît ;
  • sous quelle forme.

Authorization​

Municipal Management expose ses politiques.

Authorization ne fait que les appliquer.

Conséquences

Le module historique Mairie disparaît progressivement.

Mairie
   ↓
Territory
+
Actor
+
Municipal Management

Hors périmètre

Cette RFC ne traite pas :

  • MairieSuite ;
  • l'interface Workspace ;
  • les permissions ;
  • les publications ;
  • les notifications ;
  • la migration SQL.

Elle ne traite que les frontières métier.

Migration

La migration doit être incrémentale.

Étape 1​

Créer le nouveau contexte.

Aucun comportement modifié.

Étape 2​

Déplacer progressivement :

  • élus ;
  • collectes ;
  • informations pratiques ;
  • services municipaux.

Étape 3​

Déplacer les alertes.

Supprimer acteur_alertes.

Étape 4​

Supprimer le module historique Mairie.

Risques

Les dépendances sont identifiées.

Le principal risque est de conserver des écritures croisées pendant la transition.

Critères de succès

La RFC est terminée lorsque :

  • aucune logique métier municipale ne subsiste dans Mairie ;
  • Territory ne possède plus aucune logique municipale ;
  • Actor ne possède plus aucune logique municipale ;
  • toutes les opérations municipales passent par Municipal Management ;
  • les publications municipales transitent par des contrats ou des événements ;
  • acteur_alertes a disparu ;
  • aucune écriture croisée ne subsiste.

Rollback

Chaque étape est indépendante.

Le rollback consiste à revenir au commit précédent de la migration concernée.

Aucune étape ne doit rendre impossible le retour en arrière.

Structure recommandée des futures RFC

Chaque RFC devrait comporter trois parties :

  1. Le problème : pourquoi l'architecture actuelle n'est plus satisfaisante.
  2. La décision : ce qui est retenu et pourquoi.
  3. Le plan de migration : comment mettre en œuvre la décision de manière incrémentale.