📇 Carte #4 : Shared Kernel

Vue Rapide

🎯 Objectif : Deux équipes partagent du code et un modèle commun

👥 Relation d’équipe : Mutuellement Dépendant

📊 Couplage : Très haut (code partagé)

Concept

Deux contextes partagent du code source et un modèle de domaine commun.

Shared Kernel (Code + Model)
    ↙         ↘
Team A      Team B

Le noyau partagé n’appartient à aucun contexte, il est gardé par les deux.

Quand l’Utiliser ? ✅

✅ Deux équipes très dépendantes l’une de l’autre
✅ Créer une interface prendrait plus de temps qu’un code partagé
✅ Les équipes veulent vraiment collaborer
✅ Le code partagé est stable et bien défini
✅ C’est une zone de frontière claire (pas du fouilli)

Exemples

Domain Entities partagées : Customer, Product (tous les services en ont besoin)
Value Objects : Money, EmailAddress (immuables, réutilisables)
Shared Policies : Règles métier communes
Shared Algorithms : Calculs complexes partagés

Quand l’Éviter ? ❌

❌ Les équipes ne se font pas confiance
❌ Le code partagé change fréquemment
❌ Vous pouvez le dupliquer (plus simple)
❌ Le code partagé n’est pas vraiment partagé (distinct par contexte)
❌ Les équipes sont géographiquement éloignées (communication difficile)

Questions Clés à se Poser 💭

Qu’est-ce qui est vraiment partagé ? (vs. similaire)
Comment gérons-nous les changements du noyau ?
Qui est responsable de maintenir le Shared Kernel ?
Qu’arrive-t-il si les équipes divergent dans leurs besoins ?
Comment versionnons-nous ce code partagé ?

Implications pour les Deux Équipes

Responsabilités Communes

✓ Maintenir ensemble le Shared Kernel
✓ Tester à fond : les changements affectent tous les contextes
✓ Documenter clairement : quoi et pourquoi c’est partagé
✓ Communiquer avant changement

Avantages

✓ Efficacité : pas de duplication ou traduction
✓ Cohérence : une seule source de vérité
✓ Collaboration : force les équipes à travailler ensemble
✓ Évolution facile : tout le monde évolue en même temps

Risques

⚠️ Couplage très fort : changement = impacte les 2 contextes
⚠️ Synchronisation lente : besoin de coordination
⚠️ Conflits : si les besoins divergent
⚠️ Cycles de dépendance : chaque équipe attend l’autre

Structure du Shared Kernel

Option 1 : Bibliothèque Partagée

shared-kernel/ (repository/package dédié)
├── domain-entities/
│   ├── Customer.ts
│   └── Product.ts
├── value-objects/
│   ├── Money.ts
│   └── EmailAddress.ts
└── policies/
    └── PricingPolicy.ts

Team A → imports shared-kernel
Team B → imports shared-kernel

Option 2 : Code Partagé dans Sous-Dossier

monorepo/
├── services/team-a/
│   ├── src/
│   └── shared/ (lien vers shared-kernel)
├── services/team-b/
│   ├── src/
│   └── shared/ (lien vers shared-kernel)
└── shared-kernel/
    ├── entities/
    ├── value-objects/
    └── policies/

Exemple Concret : E-commerce Shared Entities

Contexte

Deux équipes : Catalog et Inventory