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