La modularisation pour les nuls

Dernièrement, je me suis surpris à expliquer la modularisation d'un système d'information en prenant pour exemple une maison et sa cave : si vous descendez trop souvent à la cave, c'est le signe que quelque chose s'y trouve qui ne devrait pas s'y trouver.

Dit autrement, il est peut-être temps de remonter votre petite amie de la cave #NataschaKampusch.

Il faut faire attention avec cette expression, d'ailleurs ("descendre à la cave"), parce qu'elle possède un léger double sens. Je vous laisse faire vos recherches dans une fenêtre de navigation privée 😉

Plus sérieusement, c'est l'occasion de rappeler 2 ou 3 choses simples sur la modularisation des systèmes d'information :

• La modularisation, c'est-à-dire l'identification des contextes au sens du Domain-driven design, vise à minimiser les échanges entre ces derniers. Cependant, cela n'annule pas le besoin des contextes de discuter entre eux – sinon, ce ne serait pas un système mais plusieurs systèmes d'information. Une évidence que l'on perd parfois de vue.

• 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.

• Une fois établi que des contextes doivent communiquer, plusieurs modalités restent possibles mais certaines conduisent encore à plus de couplage que d'autres. Le but est bien sûr de minimiser le couplage entre les contextes, lieux de forte cohésion faiblement couplés entre eux.

Développons le sujet. En l'occurrence, vous pouvez :

• Procéder à des appels directs, en mémoire vive ou via le réseau selon qu'il s'agit d'un monolithe modulaire ou bien de microservices. L'inconvénient, c'est que le contexte appelant doit avoir connaissance du contexte appelé. Dans le cadre de microservices, c'est vite compliqué et cela conduit à passer par un orchestrateur, qui reste un gros SPOF (Single Point Of Failure).

• Alternativement, vous pouvez mettre en place une architecture événementielle, une Event-driven architecture (EDA). On ne peut pas rêver mieux, puisque l'émetteur d'un événement ne se préoccupe pas de savoir qui l'écoute, ni même de savoir si quelqu'un l'écoute ; et réciproquement, un contexte à l'écoute d'un événement ne se préoccupe pas de savoir qui l'a émis.

Cette architecture implique un mode de pensée réactif que beaucoup trouveront déroutant. En effet, plutôt que d'aller chercher l'information au moment où elle est requise, la pensée réactive procède en 2 temps :

• Temps 1 : le contexte écoute divers événements de son choix, en extrait l'information qui l'intéresse et la passe au filtre de son propre modèle, ce qui se traduit in fine par de la persistance. J'aime dire que l'information "sédimente".

• Temps 2 : ultérieurement, le contexte reçoit une requête au travers de son API ; il y répond en mobilisant la donnée à sa disposition.

Il devient ainsi possible de concevoir chaque contexte en faisant abstraction des autres, en se focalisant sur sa responsabilité propre. Le comportement du système dans son ensemble se découvre quant à lui à l'usage.