Aller au contenu principal

RFC-006 — Workspace as an Application

Statut​

Draft

Auteur​

Architecture DMV

ADR de référence​

  • ADR-013 — Workspace as a Private Administration Application
  • ADR-014 — Bounded Contexts and Modular Monolith

Résumé

Positionner définitivement DMV Workspace comme une application cliente de DMV Core.

Workspace n'est pas un Bounded Context.

Workspace ne possède aucun métier.

Il orchestre uniquement les cas d'usage exposés par les différents Bounded Contexts.

1. Problème

Historiquement, Workspace mélange parfois :

  • interface utilisateur ;
  • logique métier ;
  • contrôles d'autorisation ;
  • accès directs aux modèles ;
  • traitements spécifiques.

Cette situation crée :

  • une duplication de logique ;
  • des dépendances vers Laravel ;
  • des comportements différents selon les interfaces ;
  • des difficultés pour créer d'autres applications.

2. Contexte

DMV est une plateforme composée de plusieurs applications :

  • DMV Public
  • Workspace
  • Backoffice
  • MairieSuite
  • AssoSuite
  • Coach
  • futures applications

Toutes doivent partager le même cœur métier.

Workspace n'est qu'un client parmi d'autres.

3. Objectifs

  • faire de Workspace une application pure ;
  • empêcher toute logique métier dans le frontend ;
  • garantir qu'un même cas d'usage produise toujours le même résultat ;
  • préparer les futures applications DMV.

4. Hors périmètre

  • design système ;
  • composants React ;
  • organisation des pages ;
  • stratégie PWA.

5. Décision

Workspace :

  • appelle les cas d'usage exposés par DMV Core ;
  • affiche les données ;
  • gère l'expérience utilisateur ;
  • orchestre les interactions.

Workspace ne décide jamais :

  • des règles métier ;
  • des permissions ;
  • des transitions d'état ;
  • des validations métier.

Toute décision appartient au Bounded Context concerné.

6. Alternatives étudiées

Continuer à implémenter de la logique métier dans Workspace​

Rejetée.

Les autres applications devraient reproduire cette logique.

Donner un backend spécifique à Workspace​

Rejetée.

Le métier doit rester unique.

7. Impact

Les futures applications pourront être développées plus rapidement.

Les comportements resteront cohérents quel que soit le canal utilisé.

8. Plan de migration

Étape 1​

Inventorier toute logique métier présente dans Workspace.

Étape 2​

Déplacer progressivement cette logique dans les Bounded Contexts concernés.

Étape 3​

Remplacer les appels directs par des cas d'usage publiés.

Étape 4​

Supprimer les accès directs aux modèles métier.

9. Rollback

Chaque migration est indépendante.

Workspace peut temporairement conserver un ancien parcours tant que le nouveau cas d'usage est disponible.

10. Critères de succès

  • Workspace ne contient plus de logique métier ;
  • toutes les décisions passent par DMV Core ;
  • aucun accès direct aux modèles d'un autre contexte ;
  • les autres applications peuvent réutiliser exactement les mêmes cas d'usage.

11. Risques

  • oublier de déplacer certaines validations ;
  • conserver des contrôles d'autorisation côté interface ;
  • créer des API spécifiques à Workspace.

12. Questions ouvertes

  • Organisation des SDK clients ;
  • Gestion du cache ;
  • Offline partiel ;
  • Synchronisation des états.

Historique

DateAuteurModification
2026-07-22Architecture DMVCréation