Bounded contexts : pourquoi bien les designer ?

· Publié le · 2 min de lecture

J’ai déjà expliqué l’intérêt d’analyser les subdomains de son business domain, puis la différence entre subdomains et bounded contexts.

Au tour des bounded contexts eux-mêmes : à quoi ça sert de bien les designer ?

(Rappel important : les bounded contexts se créent par design, ils ne découlent pas d’une analyse du business comme les subdomains.)

À plusieurs choses.

1. Protéger vos modèles et leurs langages

C’est le plus important.

En DDD, on cherche à modéliser avec des termes métier bien choisis et non ambigus, pour que le code « parle » métier. Or parfois, un même (bon) terme a des significations différentes selon la situation. C’est le signe qu’il faut créer deux (ou plus) bounded contexts, pour que le terme n’ait qu’un seul sens par contexte.

2. Vous simplifier la vie

Même si le langage est identique, vous pouvez avoir des équipes différentes, des besoins de déploiement différents, des besoins de scalabilité différents : autant de bonnes raisons de couper ces parties en plusieurs bounded contexts.

Vous diminuez ainsi les contraintes organisationnelles sur le code, qui reste plus libre d’être la meilleure version possible de lui-même.

3. Mieux analyser votre programme et guider vos choix techniques

Et ce, grâce à la context map (la cartographie de vos bounded contexts et de leurs relations) :

  • Quels bounded contexts sont upstream ? Downstream ? (Qui dépend de qui.)
  • Lesquels appartiennent à des core subdomains et devront être choyés ? (Par exemple avec un Anti-Corruption Layer quand le core est downstream, ou un Open Host Service quand il est upstream.)
  • Lesquels appartiennent à des supporting subdomains, et peuvent stratégiquement se contenter de suivre le modèle d’un autre ? (Conformist)
  • Certaines parties pourraient-elles être partagées dans un Shared Kernel, pour éviter trop de duplication ?
  • Ou au contraire, vivre leur vie chacune dans son coin ? (Separate Ways)

Un niveau stratégique

On est ici à un niveau stratégique. Et pour nous autres développeurs, ça semble trop souvent « peu important ».

Pourtant, cette analyse est absolument clé : pour comprendre ce qu’on fait, repérer des problèmes et les fixer (ou les éviter), savoir où utiliser quel pattern et pourquoi (et pas « à l’instinct »). C’est ce niveau stratégique que j’apporte aux équipes que j’accompagne.

Au final, le code derrière :

  • a bien plus de chances d’être mieux pensé et designé
  • aura beaucoup moins de bugs
  • sera beaucoup moins jetable
  • ne sera ni over- ni under-engineered, selon son rôle et sa valeur dans le projet

Si tout ça vous intéresse, foncez lire un livre sur le DDD. Je ne fais ici que paraphraser et vulgariser des concepts qui vont beaucoup plus loin que ces survols.

Bons designs !