Aller au contenu principal

RFC-005 — Territory Refactoring

Statut​

Draft

Auteur​

Architecture DMV

ADR de référence​

  • ADR-014 — Bounded Contexts and Modular Monolith
  • RFC-001 — Municipal Management

Résumé

Faire de Territory le propriétaire unique des données territoriales de référence et supprimer toute logique métier municipale ou organisationnelle de ce Bounded Context.

1. Problème

Le modèle historique mélange :

  • territoire ;
  • mairie ;
  • données municipales ;
  • organisation ;
  • informations de diffusion.

Cette confusion rend difficile l'évolution des produits et crée des dépendances entre plusieurs contextes.

2. Contexte

Le territoire existe indépendamment des acteurs qui y exercent une activité.

Une commune conserve :

  • son identité ;
  • son code INSEE ;
  • sa géographie ;
  • ses informations administratives stables.

Les mairies, associations, commerces et autres organisations sont des acteurs rattachés à ce territoire.

3. Objectifs

  • faire de Territory la référence territoriale unique ;
  • supprimer toute logique métier municipale ;
  • rendre Territory réutilisable par tous les produits DMV ;
  • permettre plusieurs acteurs publics sur un même territoire.

4. Hors périmètre

  • cartographie ;
  • moteur de recherche ;
  • géocodage ;
  • optimisation des performances.

5. Décision

Territory devient propriétaire exclusif :

  • communes ;
  • codes INSEE ;
  • codes postaux ;
  • coordonnées géographiques ;
  • découpages administratifs ;
  • relations territoriales.

Territory ne possède jamais :

  • élus ;
  • services municipaux ;
  • collectes ;
  • alertes ;
  • collaborateurs ;
  • publications ;
  • identité des organisations.

6. Alternatives étudiées

Conserver le module Mairie actuel​

Rejetée.

Les responsabilités restent mélangées.

Fusionner Territory et Actor​

Rejetée.

Le territoire n'est pas une organisation.

7. Impact

Actor, Municipal Management, Publication, AssoSuite et Coach pourront tous référencer un territoire sans dépendance métier.

8. Plan de migration

Étape 1​

Inventorier toutes les données appartenant réellement au territoire.

Étape 2​

Déplacer les responsabilités municipales vers Municipal Management.

Étape 3​

Remplacer les dépendances directes par des références territory_id.

Étape 4​

Supprimer les derniers éléments métier présents dans Territory.

9. Rollback

Migration progressive.

Chaque extraction peut être annulée indépendamment tant que les anciens modèles sont conservés.

10. Critères de succès

  • Territory ne contient plus de logique municipale ;
  • toutes les organisations référencent un territoire ;
  • Municipal Management possède toutes les données municipales ;
  • aucune écriture croisée ne subsiste.

11. Risques

  • mauvaise répartition des responsabilités ;
  • dépendances historiques oubliées ;
  • duplication temporaire des données.

12. Questions ouvertes

  • Gestion des intercommunalités ;
  • Régions et départements ;
  • Territoires internationaux ;
  • Versionnement des référentiels territoriaux.

Historique

DateAuteurModification
2026-07-22Architecture DMVCréation