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 fonctionnel" et vous verrez qu'il n'y a rien de bien sorcier. Les deux ne sont pas rigoureusement identiques — d'autant que parler de "bounded countexts" dans les soirées mondaines vous donnera une contenance que de simples modules ne sauraient vous offrir 🥂, mais cette approximation aide vraiment à la compréhension.

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 ou, pour simplifier, les modules. Outre l'intelligibilité 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, puisque ce sont des zones de cohésion forte faiblement couplées entre elles. Partant, si vos développements occasionnent une régression, le risque est moindre qu'elle se propage aux autres modules : isolation, structurelle.

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 recouvrer en cas de retard de paiement.

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, donc 2 modules, 2 contextes, 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 sont finalement assez représentatives des raisonnements à l'œuvre lorsqu'on modularise un système.

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