Guide De Sélection

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

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