📇Carte Context Mapping #13 : Matrice de Sélection des Patterns
Vue Rapide
🎯 Objectif : Choisir le bon pattern selon votre situation
📊 Type : Guide de décision
Arbre de Décision
Q1: Les deux contextes dépendent-ils l'un de l'autre?
├─ NON, zéro dépendance
│ └─ SEPARATE WAYS ✓ (ou Independent Teams)
│
└─ OUI, il y a dépendance
│
├─ Q2: Est-ce une dépendance mutuelle (symétrique)?
│ │
│ ├─ OUI, mutuelle
│ │ │
│ │ ├─ Q3: Vous voulez partager du code?
│ │ │ ├─ OUI → SHARED KERNEL ✓
│ │ │ └─ NON → PARTNERSHIP ✓
│ │ │
│ │ └─ (Relation d'équipe: Mutually Dependent)
│ │
│ └─ NON, asymétrique (Upstream/Downstream)
│ │
│ ├─ Q3: Combien de downstream?
│ │ │
│ │ ├─ Beaucoup (3+)
│ │ │ └─ PUBLISHED LANGUAGE ✓
│ │ │
│ │ └─ Peu (1-2)
│ │ │
│ │ ├─ Q4: Collaborer sur l'interface?
│ │ │ ├─ OUI → CUSTOMER/SUPPLIER DEVELOPMENT ✓
│ │ │ └─ NON
│ │ │ │
│ │ │ ├─ Q5: Le modèle upstream convient?
│ │ │ │ ├─ OUI → CONFORMIST ✓
│ │ │ │ └─ NON → ANTICORRUPTION LAYER ✓
│ │ │
│ │ └─ (Relation d'équipe: Upstream/Downstream)
│
└─ SPÉCIAL: Découvrir un Big Ball Of Mud?
└─ BIG BALL OF MUD = symptôme (stratégie: Strangler)
Puis appliquer les patterns au nouveau code
Matrice Décisionnelle
Par Type de Relation d’Équipe
| Relation | Patterns Possibles | Couplage | Avantages | Risques |
|---|---|---|---|---|
| Independent | Separate Ways | Aucun | Vitesse, Autonomie | Duplication |
| Mutually Dependent | Shared Kernel, Partnership | Haut/Moyen | Collaboration, Cohésion | Synchronisation lente |
| Upstream/Downstream | Published Language, Customer/Supplier, Conformist, ACL | Moyen-Bas | Clarté, Scalabilité | Blocking sur upstream |
Par Situation
Situation 1: Legacy System + Nouveau Projet
Q: Pouvez-vous modifier le legacy?
├─ NON, intouchable
│ └─ ANTICORRUPTION LAYER
│ (Bubble Context protégeant le nouveau)
│
└─ OUI, progressif
└─ SEPARATE WAYS + Strangler Pattern
(Extraire nouveau, laisser legacy coexister)
Situation 2: Plateforme Core + Multiples Services
Q: Core tient-il le poids?
├─ NON, trop changements
│ └─ SEPARATE WAYS
│ (Chacun sa version)
│
└─ OUI, stable et bon
├─ Peu de consumers
│ └─ CUSTOMER/SUPPLIER DEVELOPMENT
│
└─ Beaucoup de consumers
└─ PUBLISHED LANGUAGE
(Spec stable, chacun sa traduction)
Situation 3: Deux Équipes, Même Produit (Frontend/Backend)
Q: Avez-vous du code réellement partagé?
├─ OUI (domain models, value objects)
│ └─ SHARED KERNEL + PARTNERSHIP
│
└─ NON, juste interfaces
└─ PARTNERSHIP
(API négociée, chacun son code)
Situation 4: Données Critiques Partagées
Q: Temps-réel synchronisation requise?
├─ OUI, toujours sync
│ ├─ Même équipe/code
│ │ └─ SHARED KERNEL (literal)
│ │
│ └─ Équipes différentes
│ └─ PARTNERSHIP + synchrone
│ (Risque: tightly coupled)
│
└─ NON, batch/async OK
└─ SEPARATE WAYS + Events
(Broadcast events, each reacts asynchronously)
Par Critères Techniques
Critère: Modèle Upstream Compatible?
Compatible?
├─ OUI, parfait fit
│ └─ CONFORMIST
│
└─ NON, beaucoup diffère
└─ ANTICORRUPTION LAYER
Critère: Interface Complexité
Traduction simple?
├─ OUI (champs directs)
│ └─ CONFORMIST ou ACL simple
│
└─ NON (calculs, agrégation)
└─ ACL complexe
ou chercher alternative (Published Language?)
Critère: Scalabilité
Combien de consumers?
├─ 1-2
│ └─ Upstream/Downstream simple OK
│
├─ 3-5
│ └─ Published Language commence
│
└─ 5+ ou communauté
└─ Published Language obligatoire
(ou découpler vers Independent)
Par Coût d’Intégration
Coût TRÈS haut?
├─ OUI (complexe, risqué)
│ └─ Réévaluer dépendance
│ └─ Considérer SEPARATE WAYS
│ └─ Ou créer ACL (isolation)
│
└─ NON, acceptable
└─ Choisir selon la relation d'équipe
Anti-patterns à Éviter
❌ Anti-pattern 1: Partnership Sans Communication
"On va faire de la partnership!"
→ Pas de réunions régulières
→ Changements unilatéraux
→ Dépendances cassées
Correction: Ajouter governance (réunions, process)
Ou revenir à Upstream/Downstream plus clair
❌ Anti-pattern 2: Shared Kernel Sans Propriétaire
"On partage le code!"
→ Personne ne le maintient
→ Divergence progessive
→ Chacun ajoute ses trucs
Correction: Nommer responsables du kernel
Ou réduire à vraiment partagé
❌ Anti-pattern 3: Trop d’Upstream/Downstream
"Platform est upstream de 50 services"
→ Platform bottleneck
→ Trop lent, trop tendu
Correction: Migrer vers Published Language
Ou découpler (services Independent)
❌ Anti-pattern 4: Oublier la Team Relationship
"On applique Shared Kernel"
→ Mais équipes ne communiquent jamais
→ Chaos prévisible
Correction: Pattern compatible avec relation d'équipe!
Feuille de Décision Rapide
Remplissez:
Question 1: Dépendance mutuelle ou asymétrique?
