II.2. La décomposition verticale
Dans la décomposition de notre système en microservices, nous revenons au terme “micro” qui suscite de nombreux commentaires surtout à propos de la bonne taille des services. Certaines parlent d’un granularité à l’échelle d’un modèle de données, d’une fonction métier, ou même parfois en nombre de lignes de codes.
La meilleure réponse à cette question est: "un microservice devrait faire une seule chose". Une réponse très générique, qui s'interprète de deux façons différentes :
- Soit avoir une responsabilité unique (Single Responsibility Principle), et donc une granularité à l'échelle des agrégats de notre modèle.
- Soit avoir un contexte bornée unique dans le domaine métier, et donc une granularité à l'échelle des bounded contexts.
Pour prendre la décision à ce niveau, il existe un deuxième facteur à prendre en considération dans le design. C’est la construction des services autour des équipes de développement, qui s’organisent de leur part autour des fonctionnalités métier et non des technologies. Cette organisation s’apparente aux Feature teams.
Dans une décomposition verticale de microservices en utilisant le DDD:
- Nous découpons notre domaine ou application (si monolithe) en plusieurs unités aussi indépendantes que possibles. Le découpage se fait selon les sous domaines du métier et donne lieu à des “verticales” (si aucun lien n’existe entre les sous domaines). Chacune de ces verticales appartient uniquement à une seule équipe.
- La verticale, correspondant à tout un sous domaine, reste souvent une application relativement compliquée, de sorte que l'on pourrait vouloir la diviser encore, de préférence en verticales mais aussi en simples microservices.
- Si notre contexte est très riche et compliqué, nous privilégions le découpage par agrégats (et donc l’implémentation de quelques fonctionnalités du contexte). Ce qui rend un microservice totalement compréhensible par un seul développeur.
Le découpage en microservices, au niveau de chaque verticale, donne lieu aussi à une composition par couche de responsabilité (dite parfois horizontale).
Les appels reçus depuis le point d'entrée, parcourent les services concernés par la feature, de la couche supérieure (final composite) à la couche inférieure (core). Ces derniers sont traités puis distribués sur les autres services. Les sous-résultats sont ensuite résumés en une réponse et renvoyés à la demande.
- Le design final des microservices en utilisant le DDD et la décomposition verticale, donne une schématisation similaire à celle qui figure dans le diagramme ci-dessous.
