Aller au contenu principal

RFC-007 — Product Boundaries

Statut​

Draft

Auteur​

Architecture DMV

ADR de référence​

  • ADR-000 — DMV Core & Modular Applications
  • ADR-013 — Workspace as a Private Administration Application
  • ADR-014 — Bounded Contexts and Modular Monolith

Résumé

Définir les frontières entre DMV Core et les applications de la plateforme afin de garantir qu'aucun produit ne devienne propriétaire du métier.

Les applications utilisent DMV Core. Elles ne le remplacent jamais.

1. Problème

Avec la multiplication des produits (DMV Public, Workspace, MairieSuite, AssoSuite, Coach…), un risque apparaît :

  • dupliquer la logique métier ;
  • créer des API spécifiques à chaque produit ;
  • faire dériver les modèles ;
  • créer plusieurs vérités métier.

À terme, chaque produit évoluerait indépendamment et la plateforme perdrait sa cohérence.

2. Contexte

DMV est une plateforme.

Les produits ne sont que différentes portes d'entrée vers les mêmes capacités métier.

Exemples :

  • un acteur peut être administré depuis Workspace ;
  • la même donnée peut être affichée dans DMV Public ;
  • MairieSuite manipule les capacités municipales ;
  • AssoSuite manipule les capacités associatives.

Le métier reste unique.

3. Objectifs

  • garantir une seule source de vérité métier ;
  • empêcher les produits de posséder leurs propres règles métier ;
  • permettre l'ajout de nouveaux produits sans modifier DMV Core ;
  • assurer une expérience cohérente quel que soit le canal.

4. Hors périmètre

  • UX ;
  • Design System ;
  • déploiement ;
  • authentification ;
  • stratégie commerciale.

5. Décision

Chaque produit devient une application spécialisée.

DMV Public​

Responsable de :

  • consultation publique ;
  • découverte ;
  • navigation ;
  • recherche ;
  • expérience citoyenne.

Il ne possède aucun métier.

Workspace​

Responsable de :

  • administration quotidienne des acteurs ;
  • gestion opérationnelle.

Il utilise exclusivement les cas d'usage de DMV Core.

Backoffice​

Responsable de :

  • supervision ;
  • modération ;
  • support ;
  • opérations internes.

Il n'est pas propriétaire du métier.

MairieSuite​

Responsable de l'expérience de gestion municipale.

Elle utilise :

  • Municipal Management ;
  • Publication ;
  • Actor ;
  • Territory ;
  • Authorization.

Elle ne possède pas les données métier.

AssoSuite​

Responsable de l'expérience de gestion associative.

Elle utilise :

  • Actor ;
  • Community ;
  • Publication ;
  • Authorization ;
  • futurs modules associatifs.

Coach​

Responsable de l'expérience de coaching.

Il possède son propre domaine métier.

Il peut toutefois consommer certaines capacités communes de DMV Core lorsque cela est pertinent (identité, notifications, paiements, etc.).

6. Alternatives étudiées

Un backend par produit​

Rejetée.

Le métier serait rapidement dupliqué.

Un produit propriétaire de son métier​

Rejetée.

Les autres applications ne pourraient plus réutiliser les mêmes capacités.

7. Impact

Les nouveaux produits deviennent beaucoup plus simples à développer.

Ils se concentrent uniquement sur :

  • leur interface ;
  • leur expérience utilisateur ;
  • leur orchestration.

8. Plan de migration

Étape 1​

Identifier les responsabilités actuelles de chaque application.

Étape 2​

Déplacer les règles métier vers les Bounded Contexts.

Étape 3​

Supprimer les API spécifiques lorsqu'elles ne sont plus nécessaires.

Étape 4​

Uniformiser les cas d'usage consommés par toutes les applications.

9. Rollback

Chaque application peut temporairement conserver ses anciens appels tant que les nouveaux cas d'usage existent.

10. Critères de succès

  • aucun produit ne possède de logique métier propre ;
  • DMV Core reste l'unique source de vérité ;
  • les cas d'usage sont partagés entre toutes les applications ;
  • un nouveau produit peut être développé sans modifier les règles métier.

11. Risques

  • recréer de la logique métier côté application ;
  • multiplier les API spécifiques ;
  • introduire des comportements différents selon le produit.

12. Questions ouvertes

  • stratégie SDK commune ;
  • versionnement des API ;
  • gouvernance des contrats publics ;
  • gestion des extensions propres à chaque produit.

Historique

DateAuteurModification
2026-07-22Architecture DMVCréation