Aller au contenu principal

RFC-008 — Elimination of Cross-Context Writes

Statut​

Draft

Auteur​

Architecture DMV

ADR de référence​

  • ADR-014 — Bounded Contexts and Modular Monolith
  • RFC-001 — Municipal Management
  • RFC-003 — Publication & Business Events

Résumé

Supprimer définitivement les écritures directes entre Bounded Contexts.

Chaque contexte est propriétaire exclusif de ses données.

Les interactions passent exclusivement par des commandes, des contrats publiés ou des événements métier.

1. Problème

L'analyse de l'existant met en évidence plusieurs écritures directes dans les modèles d'autres contextes.

Exemples :

  • modification directe d'une table appartenant à un autre contexte ;
  • import d'un modèle étranger pour effectuer une mise à jour ;
  • transaction couvrant plusieurs propriétaires métier.

Ces pratiques rendent les frontières d'architecture théoriques.

2. Contexte

Un Bounded Context possède :

  • ses données ;
  • ses invariants ;
  • ses décisions métier.

Aucun autre contexte ne doit modifier directement ces données.

Lorsqu'une évolution est nécessaire, le propriétaire doit recevoir :

  • une commande ;
  • ou un événement nécessitant une réaction.

3. Objectifs

  • supprimer les écritures croisées ;
  • renforcer l'ownership ;
  • réduire le couplage ;
  • rendre les migrations indépendantes ;
  • préparer une éventuelle distribution des services.

4. Hors périmètre

  • choix du bus d'événements ;
  • implémentation de l'Outbox ;
  • optimisation des performances ;
  • architecture microservices.

5. Décision

Les règles suivantes deviennent obligatoires.

Ownership​

Un contexte est le seul autorisé à modifier ses données.

Écriture​

Une demande de modification passe :

  • par une commande ;
  • ou par un cas d'usage publié.

Jamais par un accès direct.

Lecture​

Les lectures inter-contextes utilisent :

  • des contrats publiés ;
  • des projections ;
  • des modèles de lecture.

Jamais les modèles internes d'un autre contexte.

Événements​

Les faits métier sont propagés au moyen d'événements immuables.

6. Alternatives étudiées

Continuer les accès directs​

Rejetée.

Les frontières deviennent fictives.

Partager la base sans ownership​

Rejetée.

Les responsabilités deviennent impossibles à maintenir.

7. Impact

Les contextes pourront évoluer indépendamment.

Les tests deviennent plus simples.

Les migrations seront moins risquées.

Une future extraction en microservices restera possible sans refonte complète.

8. Plan de migration

Étape 1​

Inventorier toutes les écritures croisées.

Étape 2​

Identifier le véritable propriétaire métier.

Étape 3​

Créer les commandes ou cas d'usage nécessaires.

Étape 4​

Remplacer progressivement chaque écriture directe.

Étape 5​

Supprimer les dépendances restantes.

9. Rollback

Chaque remplacement est réalisé indépendamment.

Le retour consiste à réactiver temporairement le chemin précédent tant que les données restent cohérentes.

10. Critères de succès

  • aucune écriture directe dans un autre Bounded Context ;
  • aucun import d'un modèle métier étranger pour modifier ses données ;
  • toutes les modifications passent par le propriétaire du contexte ;
  • les lectures utilisent uniquement des contrats publiés ou des projections.

11. Risques

  • oublier certaines écritures historiques ;
  • créer des commandes trop génériques ;
  • déplacer de la logique métier dans les consommateurs.

12. Questions ouvertes

  • conventions de nommage des commandes ;
  • stratégie de monitoring des événements ;
  • indicateurs permettant de détecter les violations futures ;
  • automatisation de contrôles d'architecture dans la CI.

Historique

DateAuteurModification
2026-07-22Architecture DMVCréation