Carte Context Mapping #13 : Matrice de Sélection des Patterns

17 novembre 2025

📇 Carte #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?

Mutuelle → Q2
Asymétrique → Q4
Aucune → Separate Ways

Question 2 (si mutuelle): Code partagé ?

Oui → Shared Kernel
Non → Partnership

Question 3 (si asymétrique-peu): Collaborer sur design?

Oui → Customer/Supplier Development
Non → Q4

Question 4 (si asymétrique-simple): Modèle upstream OK?

Oui → Conformist
Non → Anticorruption Layer

Question 5 (si asymétrique-beaucoup): Published Language

Oui (stable, public) → Published Language
Non (instable) → Attendre stabilisation

Checklist: Ai-je Choisi le Bon Pattern?

Type d’équipe : corresponde au pattern (Mutuelle/Asymétrique/Indépendant)
Communication : fréquence OK pour maintenir pattern
Interface : clairement définie et documentée
Escalation : processus défini pour conflits
Métriques : tracking la santé de l’intégration
Rôles : clairement définis (propriétaire, maintenant)
Evolution : plan si situation change

Migrations Entre Patterns

Evolution Naturelle

Partnership (trop couplé)
    → Anticorruption Layer (découpler)
    → vers Separate Ways ou Independent

Upstream/Downstream (1-2 services)
    → Published Language (5+ services)
    → vers scalabilité

Shared Kernel (trop lourd)
    → Reduce à vraiment partagé
    → ou Partnership + moins de partage

Conformist (model drift)
    → Anticorruption Layer (adapter)
    → si drift important

Déclencheurs de Migration

Performance → Independent Teams
Communication overhead → Anticorruption / Separate Ways
Political power → Change relation d'équipe
Scalability → Published Language
Stability → Conformist → ACL

Ressources et Lectures

Domain-Driven Design par Eric Evans - Bounded Contexts
DDD Reference - Strategic Design Patterns
DDD Crew - Context Mapping
Team Topologies - Org Design + Context Mapping alignment

Utilisation en Atelier

Exercice 1: Identifier le Pattern Actuel

Pour chaque contexte:
1. Dessiner les contextes
2. Identifier la dépendance
3. Classifier équipes
4. Identifier pattern
5. Est-ce intentionnel ou accidentel?

Exercice 2: Designer le Pattern Futur

1. Où aimeriez-vous être?
2. Pattern ciblé?
3. Étapes de transition?
4. Risques?
5. Bénéfices?

Exercice 3: Matrice de Votre Système

Créer une matrice 2D:
├─ X axis: contextes (Catalog, Order, Payment, ...)
├─ Y axis: contextes (Catalog, Order, Payment, ...)
├─ Cells: pattern actuel
└─ Color code: sain vs problématique

Cas d’Usage Réel

E-commerce (Exemple)

Catalog ↔ Inventory: Shared Kernel (Product partagé)
Catalog ← Pricing: Upstream/Downstream (Published Language)
Catalog ← Search: Upstream/Downstream (Anticorruption Layer, data pipeline)
Order ↔ Billing: Partnership (négocie interface)
Order → Payment: Upstream/Downstream (Published Language)
Payment ← Analytics: Separate Ways (batch export nightly)

Relation d’équipe:

Catalog Team: Upstream pour 3 services
Product Team (Order+Billing): Partnership (mutuelle)
Ops Team (Payment, Infrastructure): Independent