Carte Context Mapping #6 : Separate Ways

📇 Carte #6 : Separate Ways

Vue Rapide

🎯 Objectif : Deux contextes se séparent complètement et se dupliquent

👥 Relation d’équipe : Indépendant

📊 Couplage : Nul (zero integration)

Concept

Les deux contextes abandonnent l’intégration et chacun gère sa propre version.

Team A        Team B
(duplique)    (duplique)
     ↓ ↓ ↓ ↓ ↓ ↓
  Chemin séparé

La philosophie : “On se sépare, c’est plus simple”

Quand l’Utiliser ? ✅

  • ✅ Le coût de l’intégration dépasse les bénéfices
  • ✅ Les contextes évoluent différemment et indépendamment
  • ✅ La duplication est acceptable (pas critique)
  • ✅ Les équipes veulent une autonomie totale
  • ✅ Les données peuvent être synchronisées via batch (pas temps-réel)

Exemples

  • Legacy System vs. Nouveau Système : on les laisse cohabiter sans parler
  • Rapport de gestion vs. Système de facturation : même données, deux lectures
  • Analytics vs. Production : duplication OK, latence acceptable
  • Deux variantes régionales : chacun son instance

Quand l’Éviter ? ❌

  • ❌ L’intégration est vraiment nécessaire
  • ❌ Les données doivent être synchronisées en temps-réel
  • ❌ La duplication coûte trop cher (complexité, maintenance)
  • ❌ Vous devez garder les données cohérentes
  • ❌ C’est une fuite d’architecture (vraiment du même domaine)

Questions Clés à se Poser 💭

  1. Pouvez-vous vraiment vous permettre de dupliquer ?
  2. Quel est le coût de maintenir 2 versions ?
  3. Comment gérez-vous la divergence entre les deux ?
  4. Qu’arrive-t-il quand un changement métier affecte les deux ?
  5. Comment synchronisez-vous les données critiques ?

Implications pour les Équipes

Chaque Équipe Indépendante

Avantages

  • ✓ Autonomie totale : chacun progresse à son rythme
  • ✓ Zéro couplage : changements sans impact mutuel
  • ✓ Simplicité : pas d’interface complexe
  • ✓ Pas de réunions de coordination !

Risques

  • ⚠️ Duplication : maintenance coûteuse
  • ⚠️ Divergence : à long terme, les deux dérivent
  • ⚠️ Incohérence : les données ne correspondent plus
  • ⚠️ Coût caché : bug fixes doivent se répéter

Stratégies de Séparation

1. Complète (Clean Break)

Before: Service A ↔ Service B (intégration)
After:  Service A    Service B (indépendant)

→ Chacun a sa DB, son code, ses workflows
→ Zéro partage

2. Partielle (avec Batch Sync)

Service A (Commandes)
    ↓ (batch export chaque nuit)
Data Lake
    ↓ (batch import chaque nuit)
Service B (Analytics)

→ Services indépendants mais données synchronisées
→ Acceptable delay: 24h

3. Avec Archive

Legacy System (ancien)
    ↓ (migration progressive)
New System (nouveau)

→ Legacy continue de tourner
→ New prend du trafic progressivement
→ Un jour legacy s'éteint

Exemple Concret : Migration Vers Nouveau Système

Avant (Separate Ways Forcés - mauvais)

Legacy Order System (10 ans)
    ↓ (désuet, lent)
Couplé fortement à: 
    - Inventory System
    - Billing System
    - Reporting System

→ Impossible à modifier sans casser tout
→ Vraiment besoin de découpler!

Stratégie de Séparation

Phase 1: Créer New Order System (indépendant)
├── Copier la data du legacy
└── Tester en parallèle

Phase 2: Dual-write (transition)
├── Writes vont aux deux systèmes
├── New System est primary source of truth progressivement
└── Reports lisent à partir du New

Phase 3: Legacy read-only (legacy devient archive)
├── Legacy continue de tourner en read-only
├── Données historiques toujours accessibles
└── Queries récentes pointent vers New

Phase 4: Sunset legacy (éteindre l'ancien)
├── Archive les données du legacy
├── Décommissionner le système
└── Sauvegardes long-term seulement

Co-existence Pendant Transition

Frontend
    ↓
API Gateway (routing intelligent)
    ├→ New System (80% du trafic)
    └→ Legacy System (20% du trafic, migration progressive)

Batch Job (chaque nuit)
    ├→ Exporte du New
    ├→ Importe dans Analytics
    └→ Archive du Legacy

Données Critiques: Synchronisation Required

Scenario: Commandes et Facturation

Vous avez décidé de découpler Order ↔ Billing

Mais les données doivent rester cohérentes!

Solution: Event-driven sync
├── Order Service publie "OrderPlaced"
├── Billing Service l'écoute
├── Crée une facture provisoire
└── OK, ils restent cohérents même indépendants

Pas besoin d'une intégration serrée!

Coûts Cachés de Separate Ways

1. Duplication initiale
   - Copier le code: 1-2 sprints

2. Maintenance double
   - Bug fixe doit se répéter: +50% effort

3. Divergence dans le temps
   - Après 12 mois: très difficile de re-coupler

4. Migration/Synchronisation
   - Quand tu veux re-coupler: très coûteux

5. Confusion organisationnelle
   - "C'est dans quel système ?"

Quand Revenir À L’Intégration ?

Signes d’alerte 🚨

❌ "Pourquoi les données ne correspondent pas ?"
❌ "On doit fixer le même bug dans 2 endroits"
❌ "C'est trop cher de maintenir 2 versions"
❌ "Les équipes veulent fusionner"

Transition Possible:

Separate Ways → Anticorruption Layer
                (re-coupler progressivement)

ou 

Separate Ways → Shared Kernel
                (si vraiment du domaine partagé)

Rôles et Responsabilités

Team A (Contexte A)

  • ✓ Possède et maintient sa version
  • ✓ Responsable de sa qualité
  • ✓ Peut changer son modèle sans concertation

Team B (Contexte B)

  • ✓ Possède et maintient sa version
  • ✓ Responsable de sa qualité
  • ✓ Peut changer son modèle sans concertation

Organisation (governance)

  • ✓ Décider quand re-coupler si besoin
  • ✓ Gérer la synchronisation critique (si applicable)
  • ✓ Monitorer la duplication coûteuse

Checklist de Mise en Place ✓

  • Vous avez vraiment décidé de vous séparer
  • Le coût de duplication est acceptable
  • Vous avez une stratégie de synchronisation (si données critiques)
  • Les équipes sont vraiment indépendantes (pas de dépendances cachées)
  • Vous avez un plan de sunset (quand éteindre l’ancien)
  • La documentation est claire sur quel système utiliser

Ressources et Lectures

  • Domain-Driven Design par Eric Evans - Separate Ways
  • Microservices Patterns par Chris Richardson - Strangler Pattern
  • DDD Crew - Context Mapping

Notes de Facilitation pour l’Atelier

Animation

  • Demandez : “Pourquoi vous voulez vous séparer ?”
  • Testez : “Que se passe-t-il si les données divergent ?”
  • Documentez : “Quel est le coût vrai ?”

Pièges Communs

  • ⚠️ Sous-estimer la duplication : “On va juste copier” → très coûteux
  • ⚠️ Données incohérentes : personne ne sait quelle version est vraie
  • ⚠️ Plan de migration flou : “On verra…”
  • ⚠️ Oublier les dépendances : découvrir tard qu’il y a des liens

Questions Provocatrices

  • “Et dans 3 ans, si vous devez re-coupler ?”
  • “Quel système est source de vérité ?”
  • “Combien coûte vraiment la duplication ?”
  • “Est-ce vraiment du separate ways ou juste du chaos ?”