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 12 février 2025
Pour une raison que j'ignore, les bounded contexts font peur comme les monstres tapis sous le lit d'un enfant. Ou comme votre manager lorsqu'il se dirige vers vous à 17h30 passées 😱
Une approximation qui a du sens
Pourtant, remplacez "bounded context" par "module fonctionnel" et vous verrez qu'il n'y a rien de bien sorcier. Les deux ne sont pas rigoureusement identiques, mais cette approximation aide vraiment à la compréhension. En revanche, notez que parler de "bounded contexts" dans les soirées mondaines vous donnera une contenance que de simples modules ne sauraient vous offrir 🥂
Tout l'objet du Domain-driven design stratégique est de découper un grand système en systèmes plus petits : les bounded contexts. Outre l'intelligibilité et les implications organisationnelles, la raison principale de vouloir des contextes est qu'ils apportent de l'isolation.
Un bon découpage minimise par définition les interactions entre contextes, puisque ce sont des zones de cohésion forte qui sont faiblement couplées les unes aux autres. Partant, si vos développements occasionnent une régression, le risque est moindre qu'elle se propage aux autres contextes : les contextes offrent une isolation structurelle.
Identification des contextes : 2 erreurs courantes
Une question demeure : comment identifier les contextes ? Et si je me trompe ?
OK. Alors évacuons tout de suite 2 grandes sources d'erreurs :
- Le découpage en couches techniques, par exemple "application" et "base de données". 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" ? La fausse bonne idée, parce 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 cet exemple :
- Émettre une facture est une finalité à part entière, cela s'appelle la facturation et 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 métier 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é et cela s'appelle 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, 2 verbes d'action ("facturer" et "recouvrer"), 2 grands ensembles de fonctionnalités, 2 modèles de données n'ayant que peu en commun, c'est-à-dire 2 contextes.
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. Et c'est rarement plus compliqué que ça (enfin, à voir).