Bounded contexts 101
2 erreurs courantes du découpage en Bounded Contexts : le découpage en couches techniques et le découpage par entités. Pensez verbes d'action !
Publié le 4 octobre 2023Dernière mise à jour le 7 juillet 2026
Je le dis et le répète à qui veut l'entendre : la modularité est la qualité première que vous devez travailler pour être en mesure de faire évoluer votre système d'information sur le long terme. Et, par chance, c'est un sujet avant tout fonctionnel, sur lequel les CEO ont prise, un sujet sur lequel ils doivent se pencher tant il concerne le cœur de métier de l'entreprise !
Modulariser un système d'information, c'est tracer les contours de ses Bounded Contexts, notion centrale du Domain-Driven Design. Pour une raison que j'ignore, elle demeure abstraite aux yeux de beaucoup d'entre nous, au point de faire peur. Dommage, car, avec l'habitude, vous verrez que ce n'est pas si compliqué.
L'intuition : une maison et une cave
Prenez l'exemple d'une maison ayant une cave : si vous descendez trop souvent à la cave, disons tous les jours, c'est le signe que quelque chose s'y trouve qui ne devrait pas s'y trouver (1). Pourquoi ? Parce qu'il y a le lieu de vie d'une part, et le lieu d'entreposage, d'autre part. Ce qui revient à dire que nous avons ici deux contextes définis par la fréquence d'accès aux objets : le "chaud" et le "froid".
Cet exemple, aussi simple soit-il, dit encore 2 choses importantes :
- Si 2 contextes parlent beaucoup ("chatty services"), c'est probablement que leurs responsabilités sont mal réparties (une responsabilité devrait être transférée de l'un à l'autre), ou bien qu'ils ne constituent qu'un seul et même contexte.
- La modularisation minimise les échanges à grande échelle, mais ne les supprime pas : les contextes doivent toujours dialoguer. Sinon, ce ne serait pas un système, mais plusieurs. Autrement dit, vous continuerez de descendre à la cave, de temps en temps. Une évidence que l'on perd parfois de vue, et qui explique bien des difficultés à modulariser.
Tout l'objet du Domain-Driven Design stratégique est de découper un grand système en sous-systèmes aussi petits que possible, les bounded contexts. Ce sont des zones de cohésion forte couplées faiblement les unes aux autres, chacune étant centrée sur une responsabilité unique.
Mais comment, concrètement, identifier les contextes d'un système donné ?
Une approximation pour éviter 2 erreurs courantes
En première approximation, un bounded context peut être assimilé à un module fonctionnel. Les deux ne sont pas rigoureusement identiques, le premier allant plus loin dans le découpage que le second, mais cette approximation aide vraiment à la compréhension.
Cette approximation est importante parce qu'elle dit l'essentiel, à savoir que ce découpage est basé sur des considérations bien plus liées au métier qu'à la technique. Elle permet surtout d'éviter 2 erreurs fréquentes :
- Le découpage en couches techniques, par exemple "application" et "base de données". Ce découpage ne tient pas, parce que les 2 servent la même finalité métier et ne cessent d'interagir pour cela. Le modèle physique découle du modèle logique, les dissocier n'aurait aucun sens.
- Le découpage en entités : un contexte "factures", par exemple. Aussi séduisant soit-il, c'est une fausse bonne idée. Pour s'en convaincre, il faut considérer que l'on peut vouloir faire des choses très différentes avec une facture, à commencer par l'émettre et la recouvrer en cas de retard de paiement.
Identification des contextes : penser "verbes d'action"
Creusons un peu l'exemple précédent :
- Émettre une facture est une finalité à part entière (la facturation), qui requiert de connaître la raison sociale du client, la référence des produits ou services vendus et leur prix ainsi que les taux de TVA applicables, les conditions contractuelles (calendrier de facturation, délais de paiement…) sans oublier un numéro de séquence. L'émission de factures peut être très spécifique au modèle commercial de l'entreprise et nécessiter de nombreux développements.
- Obtenir le paiement de cette même facture une fois l'échéance passée est une autre finalité (le recouvrement). Pour les personnes en charge de cette activité, peu importe que vous vendiez des barils de pétrole ou des huîtres, seuls comptent le montant à recouvrer et le retard de paiement. Le recouvrement n'est pas lié au cœur de métier de l'entreprise, si bien qu'on utilise généralement un outil ou un service tiers.
Ainsi, pour une même facture, ce sont 2 finalités distinctes, des verbes d'action distincts (facturer et recouvrer) et en fait des vocabulaires distincts, qui signent 2 bounded contexts. Un bounded context est une zone où un terme du langage possède un sens unique, définition d'Eric Evans, père du DDD.
On pourrait en dire bien plus sur le sujet, mais ces quelques lignes sont finalement assez représentatives des raisonnements à l'œuvre lorsqu'on modularise un système. Si vous ne devez retenir qu'une chose : ne pas découper par entité mais par action (ce que l'on fait avec ces entités).
Ce découplage offre des bénéfices multiples : intelligibilité du système dans son ensemble (chaque contexte travaille dans une relative autonomie), isolation structurelle et résilience (si vos développements occasionnent une régression, le risque est moindre qu'elle se propage aux autres contextes), sans oublier qu'ils vous offrent sur un plateau la définition de vos équipes (loi de Conway inversée, où chaque contexte sera pris en charge par une et une seule équipe).
(1) Dit autrement, il est peut-être temps de remonter votre petite amie de la cave #NataschaKampusch.