📇 Carte #3 : Conformist

Vue Rapide

🎯 Objectif : L’équipe downstream adopte le modèle upstream sans traduction

👥 Relation d’équipe : Upstream/Downstream (asymétrique)

📊 Couplage : Haut (adhérence au modèle upstream)

Concept

L’équipe downstream accepte simplement le modèle et les conventions de l’équipe upstream.

Upstream (modèle de référence)
    ↓ (pas de traduction)
Downstream (adopte le même modèle)

La philosophie : “Ce que vous donnez, nous l’utilisons tel quel”

Quand l’Utiliser ? ✅

✅ Le modèle upstream est suffisamment bon pour votre besoin
✅ Créer une ACL serait trop complexe ou non rentable
✅ L’upstream est stable et bien conçu
✅ Vous avez une dépendance forte et c’est acceptable
✅ L’équipe upstream a du poids politique ou est essentielle

Exemples

API publique stable : Adopter directement une API bien conçue
Plateforme core : Tous les services acceptent le modèle core
Standard industrie : Utiliser un standard reconnu (ISO, RFC, etc.)

Quand l’Éviter ? ❌

❌ Le modèle upstream est incompatible avec votre domaine
❌ L’upstream change fréquemment sans coordination
❌ Vous avez besoin de dépendances croisées (Partner pattern est meilleur)
❌ C’est une dépendance temporaire (better: Anticorruption Layer)
❌ Le modèle upstream est mal conçu (Big Ball Of Mud)

Questions Clés à se Poser 💭

Est-ce que le modèle upstream nous convient vraiment ?
Allons-nous devoir le modifier plus tard ?
Quels sont les risques de cette adhérence ?
Comment restons-nous informés des changements ?
Qui décide des évolutions du modèle shared ?

Implications pour l’Équipe Downstream

Responsabilités

✓ Accepter le modèle tel qu’il est
✓ Communiquer rapidement si le modèle pose problème
✓ Collaborer avec upstream pour améliorations
✓ Supporter les changements d’upstream

Avantages

✓ Simple : pas de couche de traduction
✓ Rapide à intégrer : implémentation directe
✓ Couplage intentionnel : c’est du domaine partagé
✓ Moins de bugs : une seule source de vérité

Risques

⚠️ Pollina votre modèle : compromis sur votre pureté
⚠️ Couplage fort : difficile à défaire
⚠️ Bloqué par upstream : changements lents
⚠️ Conflit de visions : deux domaines, une structure

Implications pour l’Équipe Upstream

Responsabilités

✓ Maintenir une API stable : les downstream dépendent de vous
✓ Communicer les changements : informer rapidement
✓ Respecter la compatibilité : ou avoir un processus de migration
✓ Écouter les besoins downstream

Avantages

✓ Influence : votre modèle devient référence
✓ Couplage maîtrisé : par design

Risques

⚠️ Responsabilité : you break it, you own all the consequences
⚠️ Évolution lente : devoir négocier avec tous les conformists

Exemples de Conformist Patterns

1. Shared Business Model

Upstream Team (Orders Domain)
    ├── Order { id, customerId, items, status }
    ├── OrderItem { productId, quantity, price }
    └── Status enum

Downstream Team (Invoicing)
    └── Adopte exactement le même modèle
        ├── Invoice utilise Order directement
        ├── InvoiceItem utilise OrderItem
        └── Respecte Status enum

2. API Publique Standard

Upstream: REST API (JSON well-known)
    {
      "id": "...",
      "name": "...",
      "type": "...",
      "metadata": { ... }
    }

Downstream Services:
    └── Tous utilisent exactement cette structure
        Pas de traduction

3. Industrie Standard (XML/JSON Schema)

Standard: UBL Invoice
    Upstream (supplier): génère UBL
    Downstream (customer): consomme UBL
    → Pas de traduction

Exemple Concret : Plateforme E-commerce

Contexte

Vous avez une équipe Product Core qui gère l’essai central.