Atelier de Cartographie de Contexte : Mapper les Relations Socio-Techniques

Atelier de Cartographie de Contexte

Étape 6 du DDD Starter Modelling Process : “Organise”

(2h à 3h, idéal 8-20 participants)

Contexte : Où sommes-nous dans le DDD Starter Modelling Process ?

Cet atelier intervient après :

  • ✅ EventStorming : Vous avez découvert le domaine collaborativement
  • ✅ Décomposition en sous-domaines : Vous avez identifié les délimitations naturelles
  • ✅ Analyse stratégique : Vous avez identifié vos core domains
  • ✅ Domain Message Flow : Vous avez modélisé les flux end-to-end

Maintenant, il s’agit d’organiser les équipes et de clarifier les patterns d’intégration entre contextes. La cartographie de contexte répond à la question :

“Comment organiser nos équipes et nos relations d’intégration pour que nous travaillions de manière autonome mais coordonnée ?”

Objectifs de l’Atelier

À la fin de cet atelier, vous devez avoir :

  1. ✅ Une carte visuelle des bounded contexts avec leurs relations explicites
  2. ✅ La classification des relations (mutuellement dépendants, upstream/downstream, libres)
  3. ✅ Le sélection de patterns d’intégration pour chaque relation
  4. ✅ Une identification des anti-patterns à corriger (ex: Big Ball Of Mud)
  5. ✅ Une vision commune entre toutes les équipes sur la socio-technologie

Design de l’Atelier

1. Introduction (15 min)

Présentation du Domain-Driven Design et des contextes délimités

  • Concept de bounded context : frontière explicite autour d’un domaine
  • Pourquoi les contextes multiples sont inévitables dans les grands systèmes
  • Loi de Conway : l’architecture reflète la structure organisationnelle

Distribution des ressources

  • Chaque sous-groupe reçoit un template de carte de contexte
  • Exemples visuels des 9 patterns
  • Sticky notes et marqueurs pour la cartographie collaborative

2. Phase 1 : Identification des Contextes (30 min)

Brainstorming collectif sur la structure actuelle

  • “Quels sont nos services/domaines principaux ?”
  • “Quelles sont les responsabilités distinctes ?”
  • “Où s’arrête un domaine et où en commence un autre ?”

Première cartographie murale

  • Dessiner les bulles (bounded contexts) sur le mur
  • Nommer clairement chaque contexte
  • Identifier les équipes responsables

Questions de clarification

  • “Y a-t-il des zones grises entre les contextes ?”
  • “Où voyez-vous du ‘Big Ball Of Mud’ ?”
  • “Quels contextes sont isolés vs. interdépendants ?”

3. Phase 2 : Cartographie des Relations (50 min)

Identifier les dépendances réelles

Par paire de contextes, discuter :

  • “Ces deux contextes doivent-ils interagir ?”
  • “Qui dépend de qui ?”
  • “Quelle est l’asymétrie (s’il y en a une) ?”

Type de relation d’équipe

Pour chaque interaction, classifier :

  • Mutuellement dépendants : Les deux réussissent ou échouent ensemble
  • Upstream/Downstream : Un contexte influence l’autre de manière asymétrique
  • Libres : Aucune relation intentionnelle

Sélectionner les patterns d’intégration

Pour chaque relation, choisir parmi les 9 patterns et justifier :

Les 9 Patterns Détaillés

1. Open-host Service

  • L’équipe upstream expose une interface (API, événements, etc.) ouverte
  • Tous les clients downstream peuvent l’utiliser
  • L’interface évolue pour accommoder de nouveaux besoins
  • ✅ Quand : Plusieurs clients downstream, peu de besoins idiosyncratiques
  • ❌ Pas bon pour : Relations très asymétriques ou besoins très spécifiques

2. Conformist

  • L’équipe downstream adopte le modèle et le langage de l’upstream
  • Pas de traduction, pas de couche d’adaptation
  • Simplifie l’intégration mais limite l’indépendance downstream
  • ✅ Quand : Upstream très dominant, pas d’objection sémantique
  • ❌ Pas bon pour : Besoins radicalement différents

3. Anticorruption Layer (ACL)

  • L’équipe downstream crée une couche de traduction
  • Protège son propre domaine du modèle upstream
  • Permet une évolution indépendante
  • ✅ Quand : Modèles radicalement différents, besoin d’indépendance
  • ❌ Pas bon pour : Relations très simples, surcoût de complexité

4. Shared Kernel

  • Deux équipes partagent explicitement une partie du modèle de domaine
  • Code/base de données commune pour cette partie
  • Changements coordonnés pour cette partie
  • ✅ Quand : Noyau métier critique commun aux deux
  • ❌ Pas bon pour : Nombreuses interactions, besoins divegents

5. Partnership

  • Deux équipes collaborent fortement sur l’évolution des interfaces
  • Planification coordonnée et jointe
  • Dépendances multiples et interdépendantes
  • ✅ Quand : Contextes mutuellement dépendants, équipes colocalisées
  • ❌ Pas bon pour : Nombreux contextes, overhead de coordination

6. Customer/Supplier Development

  • Relation formelle client/fournisseur
  • L’équipe downstream a un rôle de “client” dans la planification upstream
  • Négociation des besoins, budgétisation des tâches
  • ✅ Quand : Upstream peut réussir sans downstream, mais downstream prioritaires pour upstream
  • ❌ Pas bon pour : Mutuellement dépendants (voir Partnership)

7. Published Language

  • Langage commun, bien documenté, pour exprimer les concepts métier
  • Standards partagés (format, ontologie)
  • Traductions vers/depuis ce langage
  • ✅ Quand : Nombreux contextes, besoin de communication claire
  • ❌ Pas bon pour : Relation simple entre deux contextes

8. Separate Ways

  • Pas d’intégration intentionnelle
  • Chaque contexte évolue indépendamment
  • Intégration ad-hoc seulement si nécessaire
  • ✅ Quand : Véritablement aucune dépendance
  • ❌ Pas bon pour : Il y a de vraies dépendances cachées

9. Big Ball Of Mud

  • ⚠️ Anti-pattern : Contexte mal défini, modèles mélangés
  • Pas de limites claires
  • Impossible de faire évoluer indépendamment
  • Stratégie : Isoler progressivement en créant une Anticorruption Layer autour

4. Phase 3 : Validation et Challenge (30 min)

Présentation par équipe

Chaque équipe/groupe présente sa portion de la carte :

  • Les contextes qu’ils gèrent
  • Les relations avec d’autres contextes
  • Les patterns choisis

Questions de challenge croisé

Les autres groupes questionnent :

  • “Pourquoi ce pattern plutôt qu’un autre ?”
  • “Avez-vous oublié une dépendance ?”
  • “Voyez-vous du ‘Big Ball Of Mud’ que vous n’avez pas nommé ?”
  • “Est-ce que cette relation reflète la réalité ou l’idéal ?”

Ajustements collectifs

Intégrer les retours dans la carte globale

5. Phase 4 : Analyse de la Carte Complète (25 min)

Identification des hotspots

  • Quels contextes sont sur-sollicités ?
  • Quels contextes sont isolés alors qu’ils devraient interagir ?
  • Où voyez-vous des frictions ?

Analyse socio-technique

  • La carte reflète-t-elle la réalité organisationnelle ?
  • Y a-t-il des désalignements entre structure d’équipe et structure technique ?
  • Comment ces désalignements créent-ils des problèmes ?

Opportunités d’amélioration

  • “Quel pattern pourrait améliorer la situation ?”
  • “Devrions-nous réorganiser certains contextes ?”
  • “Devrions-nous créer une Anticorruption Layer quelque part ?”

6. Conclusion / Prochaines Étapes (10 min)

Résumé de la carte

Présenter la version finale de la cartographie

Prochaines actions

  • Valider la carte avec des parties prenantes absentes
  • Documenter les patterns et les justifications
  • Établir un plan pour éviter/sortir du “Big Ball Of Mud”
  • Planifier des reteaming si désalignements importants

Invitation à prolonger

  • Blog : articles détaillés sur chaque pattern
  • Ateliers de suivi pour affiner la carte
  • Implémentation progressive des patterns

Les 9 Cartes en Référence

Relations d’équipes (3 types)

  1. Mutuellement Dépendants

    • Les deux contextes/équipes doivent réussir ensemble
    • Forte coordination nécessaire
    • Déploiements souvent couplés

  2. Upstream/Downstream

    • Relation asymétrique
    • L’upstream peut réussir sans le downstream
    • Le downstream ne peut pas réussir sans l’upstream

  3. Libres

    • Aucune dépendance intentionnelle
    • Évolutions complètement indépendantes
    • Couplage accidentel indésirable

Patterns (9 patterns)

Pattern Description Quand l’utiliser Risques
Open-host Service Interface commune exposée Plusieurs clients, besoins similaires Peut devenir trop générique
Conformist Downstream adopte le modèle upstream Upstream très dominant Perte d’indépendance
Anticorruption Layer Couche d’isolation et traduction Modèles très différents Complexité supplémentaire
Shared Kernel Partage explicite d’une partie du domaine Noyau critique commun Couplage sémantique
Partnership Collaboration forte sur les interfaces Mutuellement dépendants Overhead de coordination
Customer/Supplier Development Relation client/fournisseur formelle Upstream indépendant mais coopératif Peut créer de la friction
Published Language Langage commun documenté Nombreux contextes Complexité de maintenir le standard
Separate Ways Pas d’intégration intentionnelle Vraiment aucune dépendance Risque de dépendances cachées
Big Ball Of Mud Anti-pattern à éviter Isoler progressivement Évoluer devient impossible

Questions pour Animer la Discussion

Phase 1 : Identification des Contextes

  • Quels domaines métier distincts identifiez-vous ?
  • Comment les équipes sont-elles actuellement organisées ?
  • Y a-t-il des zones qui ne sont claires pour personne ?
  • Où voyez-vous des zones grises ou du chaos ?

Phase 2 : Cartographie des Relations

  • Comment ce contexte communique-t-il avec celui-ci ?
  • Qui initie les changements : l’upstream ou le downstream ?
  • Quel pattern décrit le mieux cette interaction actuelle ?
  • Quel pattern améliorerait cette interaction ?

Phase 3 : Validation

  • Ce pattern reflète-t-il la réalité ou l’intention ?
  • Voyez-vous des problèmes d’implémentation dans ce pattern ?
  • Y a-t-il des dépendances implicites que nous n’avons pas nommées ?

Phase 4 : Analyse

  • Où voyez-vous du “Big Ball Of Mud” ?
  • Où vois-tu de la friction dans la collaboration ?
  • Comment cette carte nous aide-t-elle à prendre de meilleures décisions ?
  • Quels changements devraient être prioritaires ?

Artefacts de Sortie

Carte visuelle

  • Diagramme affichable des contextes et relations
  • Légende des patterns utilisés
  • Identification des hotspots

Documentation

  • Description de chaque contexte
  • Justification du pattern choisi pour chaque relation
  • Risques identifiés
  • Plan d’action pour les amélirations

Prochaines Étapes

  • Ateliers de suivi par zone
  • Implémentation progressive des patterns
  • Reteaming si nécessaire

Après la Cartographie de Contexte : Continuation du DDD Starter Modelling Process

Une fois que vous avez une Context Map validée, vous êtes prêt pour passer aux étapes suivantes :

Étape 7 : Define - Bounded Context Canvas

Pour chaque bounded context identifié dans votre cartographie :

  • Utiliser le Bounded Context Canvas pour détailler les responsabilités
  • Clarifier les entrées/sorties (APIs, événements)
  • Identifier les dépendances externes explicitement

Outil recommandé : Bounded Context Canvas

Étape 8 : Code - Aggregate Design Canvas

Pour chaque contexte, modéliser les agrégats :

  • Utiliser l’Aggregate Design Canvas pour designer les entités racines
  • Clarifier les comportements et invariants
  • Valider les limites des agrégats avec la Context Map

Outil recommandé : Aggregate Design Canvas

Itération et Feedback

  • La Context Map n’est pas figée - elle évolue avec votre compréhension
  • Chaque semaine/sprint, revisiter la carte au fur et à mesure que vous codez
  • Les insights du code peuvent remettre en question la cartographie
  • C’est normal et attendu : c’est comme ça qu’on fait du DDD

Ressources pour Continuer