Bounded contexts 101

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.

Pourtant, remplacez "bounded context" par "module" et vous verrez qu'il n'y a rien de sorcier, tandis que vous détiendrez un outil concret et actionnable pour structurer votre codebase sur le long terme.

À dire vrai, les deux ne sont pas totalement équivalents : parler de "bounded countexts" dans les soirées mondaines vous donnera une contenance que de simples modules ne sauraient vous offrir 🥂

Passons.

Tout l'objet du Domain-driven design stratégique est de découper un grand système en systèmes plus petits : nos modules.

Outre l'intelligibilité (il est plus facile de trouver ce que l'on cherche quand l'ensemble est rigoureusement partitionné) et les implications organisationnelles, la raison principale de vouloir des modules est qu'ils apportent de l'isolation.

Un bon découpage minimise par définition les interactions entre modules (lieux de cohésion forte, faiblement couplés entre eux). Partant, si vos développements occasionnent une régression, le risque est moindre qu'elle se propage aux autres modules.

Une question demeure : comment identifier les modules ? 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 mettre au recouvrement.

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 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'il est généralement délégué à 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, donc 2 modules, 2 contextes et parfois 2 applications, en tout cas 2 modèles de données n'ayant que peu en commun (*).

On pourrait en dire bien plus sur le sujet, mais ces quelques lignes constituent un bon premier aperçu des raisonnements à l'œuvre lorsqu'on modularise un système.

Et c'est rarement plus compliqué que ça.

(*) À bien y regarder, le montant de la facture n'a d'ailleurs pas besoin d'être stocké dans le module "facturation", puisqu'il peut être calculé à partir de données élémentaires qu'il faut de toute façon persister. En revanche, c'est une information que l'on voudra stocker telle quelle dans le module "recouvrement", puisqu'il ne la calcule pas.