📇 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 💭

Pouvez-vous vraiment vous permettre de dupliquer ?
Quel est le coût de maintenir 2 versions ?
Comment gérez-vous la divergence entre les deux ?
Qu’arrive-t-il quand un changement métier affecte les deux ?
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