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 :

Pourquoi la Cartographie de Contexte ?

La cartographie de contexte est une technique fondamentale du Domain-Driven Design (DDD) qui permet de visualiser les relations entre les contextes délimités (bounded contexts) et les équipes qui les gèrent. Elle répondrait à une problématique majeure en architecture logicielle : comment comprendre et gérer les dépendances dans un système complexe composé de multiples services ou modules ?

Le problème architectural traditionnel

En architecture logicielle, on observe souvent :

🔗 Dependency Breakers: Identifier et Briser les Dépendances Problématiques

Introduction

Toute architecture complexe accumule des dépendances. Mais pas toutes les dépendances sont bonnes. Certaines deviennent problématiques : elles ralentissent, bloquent, créent du risque, ou violent l’autonomie des équipes.

Ce guide vous aide à :

1. Identifier les dépendances problématiques
2. Comprendre pourquoi elles posent problème
3. Appliquer des patterns pour les “briser” (dependency breakers)

---

Partie 1: Diagnostiquer les Dépendances Problématiques

Qu’est-ce qu’une Dépendance Problématique?

Une dépendance est problématique si elle a une ou plusieurs de ces caractéristiques:

Cet article traite de la stratégie technique par rapport à la diversité des composants, produits, options disponibles et à leur évolution.

Nous avons déjà parlé de l’importance de formaliser et enregistrer les décisions d’architecture avec les ADRs.

Ici, nous allons voir quelques outils stratégiques de représentation des informations qui puissent servir à aligner les moyens techniques aux besoins.

L’intérêt réside dans la dynamique d’utilisation de ces outils. Il ne s’agit pas de créer une photo figée mais bien d’itérer et d’adapter pour

En ce début 2021, nous poursuivons les séances de mob avec Anthony et Guillaume avec le challenge de code “Rover on Mars”.

Après un premier cycle rapide directement dans le code, nous sommes gênés par la complexité croissante de certaines classes qui font beaucoup trop de choses et chaque petite modif commence à coûter. Nous nous posons la question de comment séparer tout ça avec des avis partagés. Ce qu’appelle la noirceur du fond d’écran de VSCode, c’est qu’il nous manque un tableau blanc.

My notes from SAFe 5.0 training videos

SAFe for Architects course trainers should have the following experience:

• Experience architecting using Agile principles
• Experience guiding teams through implementation
• Experience with full life-cycle delivery

SAFe Architect responsibilities:

• Aligner l’architecture aux principes SAFe / ?
• Développer et communiquer la vision et l’intention de l’architecture
• Planifier la ligne d’architecture pour des livraisons réussies
• Construire l’architecture pour livrer en continu et releaser à la demande
• Guider et coacher les architectes et les membres d’équipe durant le PI Planning et l’exécution
• Leadership durant la transformation Lean-Agile

1. Exemplify Agile Architecture

• 1.1 Décrire l’architecture Agile
• 1.2 Décrire les rôles impliqués dans l’architecture et leur collaboration
• 1.3 Les principes SAFe liés à l’architecture

Exercice: Potential issue & Resolved issue board .

Ne cherchez pas de contrepetterie dans ce sous-titre !

En disant cela, vous êtes tenté bien sûr d’en trouver une. Curieusement l’attirance pour le défit ou l’interdit passe souvent avant l’exécution d’une directive ou même l’application d’un conseil.

Tout le monde se rappelle que dans le manifeste agile il est écrit “un logiciel qui fonctionne plutôt qu’une documentation exhaustive”. Cette phrase a autorisé à braver le caractère obligatoire et exhaustif de la documentation, par effet de balancier. Il revient d’ailleurs assez souvent que l’on me dise que dans les projets agiles, la documentation est trop incomplète voire complètement absente.