Aujourd’hui j’aimerais te parler d’un sujet qui revient très souvent, et qui mène régulièrement à de l’overengineering dans les équipes pourtant bien intentionnées.
Bounded Context (BC) ou Module ? Comment faire la différence ? Quels impacts ? Deux heuristiques simples en fin de post 👇
Un BC défini un périmètre dans lequel des termes ont un certain sens. Exemple tout bête : un "produit" au sens e-commerce n'est pas la même chose qu'un "produit" au sens mathématique du terme.
Nous avons donc ici deux BC distincts, qui expriment chacun leur propre "ubiquitous language" (UL).
Chaque BC est responsable de ses données, a sa propre base de données (ou son propre schéma).
La communication entre BC est idéalement découplée :
👉 par messages / events à travers un bus : limite le "temporal coupling" entre les BC, implique par contre de gérer toute l'infrastructure derrière, l'indempotence, les retry patterns, éventuellement le at least once delivery, etc.
👉 par request / reply type API HTTP / RPC : simple à mettre en place, mais crée du "temporal coupling". Il faut alors implémenter des patterns comme des circuit breaker par exemple, pour éviter les effets boule de neige lorsqu'un service tombe.
👉 par appels direct de fonctions si les bounded context sont dans le même repository et dans le même langage : la plus simple, à condition de créer des facades entre les bounded context pour exposer uniquement une API publique (au sens interface). Ça implique que le même langage de programmation soit utilisé partout, au sein d'un même repository. Ça nécessite aussi plus de travail si l'on veut passer en microservices totalement indépendant.
Quid des modules alors ?
Un module c'est simplement une façon d'organiser son code au sein d'un BC. Différents modules partagent donc le même UL.
L'idée est que le code soit le plus cohésif possible au sein d'un module (tout ce qui doit changer ensemble se trouve au même endroit dans le code), et que le couplage soit approprié entre les modules (loi de Demeter, Tell Don't Ask, SRP, etc.)
Au sein d'un même BC, le même langage de programmation est généralement utilisé, on peut donc très simplement importer des fichiers d'un module A depuis un module B. En gardant à l'esprit la forte cohésion et le faible couplage.
On remarque qu'il y a donc beaucoup moins de complexité dans la communication entre les modules comparée à celle entres bounded context.
Par conséquent, dans un nouveau projet, voici ce que je conseille :
✅ Commence par un seul BC. Le début du projet c'est là où tu en sais généralement le moins sur les frontières logiques de ton application. Mets donc tout au même endroit. C'est plus facile de séparer en d'autres BC à mesure que tu en apprends plus que réunir plusieurs BC en un.
✅ Créer des modules au sein de ton BC pour représenter différents "aspects" de ton BC. Si tu te rends compte que le module évolue vers un UL différent du BC, promeus-le en nouveau BC.
Tu vas réaliser que tu auras beaucoup moins de BC que tu ne l'imagines de la sorte :)
Partagez ce post
bounded context ou module ?
Partagez ce post
Hello !
Aujourd’hui j’aimerais te parler d’un sujet qui revient très souvent, et qui mène régulièrement à de l’overengineering dans les équipes pourtant bien intentionnées.
Bounded Context (BC) ou Module ? Comment faire la différence ? Quels impacts ? Deux heuristiques simples en fin de post 👇
Un BC défini un périmètre dans lequel des termes ont un certain sens. Exemple tout bête : un "produit" au sens e-commerce n'est pas la même chose qu'un "produit" au sens mathématique du terme.
Nous avons donc ici deux BC distincts, qui expriment chacun leur propre "ubiquitous language" (UL).
Chaque BC est responsable de ses données, a sa propre base de données (ou son propre schéma).
La communication entre BC est idéalement découplée :
👉 par messages / events à travers un bus : limite le "temporal coupling" entre les BC, implique par contre de gérer toute l'infrastructure derrière, l'indempotence, les retry patterns, éventuellement le at least once delivery, etc.
👉 par request / reply type API HTTP / RPC : simple à mettre en place, mais crée du "temporal coupling". Il faut alors implémenter des patterns comme des circuit breaker par exemple, pour éviter les effets boule de neige lorsqu'un service tombe.
👉 par appels direct de fonctions si les bounded context sont dans le même repository et dans le même langage : la plus simple, à condition de créer des facades entre les bounded context pour exposer uniquement une API publique (au sens interface). Ça implique que le même langage de programmation soit utilisé partout, au sein d'un même repository. Ça nécessite aussi plus de travail si l'on veut passer en microservices totalement indépendant.
Quid des modules alors ?
Un module c'est simplement une façon d'organiser son code au sein d'un BC. Différents modules partagent donc le même UL.
L'idée est que le code soit le plus cohésif possible au sein d'un module (tout ce qui doit changer ensemble se trouve au même endroit dans le code), et que le couplage soit approprié entre les modules (loi de Demeter, Tell Don't Ask, SRP, etc.)
Au sein d'un même BC, le même langage de programmation est généralement utilisé, on peut donc très simplement importer des fichiers d'un module A depuis un module B. En gardant à l'esprit la forte cohésion et le faible couplage.
On remarque qu'il y a donc beaucoup moins de complexité dans la communication entre les modules comparée à celle entres bounded context.
Par conséquent, dans un nouveau projet, voici ce que je conseille :
✅ Commence par un seul BC. Le début du projet c'est là où tu en sais généralement le moins sur les frontières logiques de ton application. Mets donc tout au même endroit. C'est plus facile de séparer en d'autres BC à mesure que tu en apprends plus que réunir plusieurs BC en un.
✅ Créer des modules au sein de ton BC pour représenter différents "aspects" de ton BC. Si tu te rends compte que le module évolue vers un UL différent du BC, promeus-le en nouveau BC.
Tu vas réaliser que tu auras beaucoup moins de BC que tu ne l'imagines de la sorte :)
Happy Coding !
PS : Tu bénéficies 40% de remise sur Craft Academy puisque tu es inscrit à ma newsletter :)