Un microservice est avant tout une unité fonctionnelle. Il correspond à une fonctionnalité précise, logique et cohérente du système. Un microservice est donc autonome vis à vis de la fonctionnalité qu’il réalise. Il a son propre code, gère ses propres données et ne les partage pas, pas directement en tout cas, avec d’autres services. L’approche nécessite un effort de conception pour faire émerger des unités fonctionnelles autonomes.
Pour parvenir à un résultat cohérent au niveau du service en lui-même et au niveau global du SI (vision de l’urbaniste) plusieurs idées :
- Séparer la complexité fonctionnelle et technique : le service répond à un besoin fonctionnel, pas applicatif !
- Eviter le couplage entre services. S’il y en a trop le contexte est peux être mal délimité !
- Trouver un équilibre entre macroservices et nanoservices.
Pour arriver à ce résultat, nous pouvons utiliser l’approche Domain Driven Design d’Eric Evans qui a largement fait ces preuves. DDD, proposé par Evans dès 2003, est une manière de penser la conception autour du code, de collaborer et de communiquer (via un langage commun et clairement définis) avec les experts fonctionnels et d’avoir une implémentation centrée sur le métier. Le besoin de cohérence fonctionnelle très forte au niveau du découpage de microservices se recoupe très bien avec l’approche DDD.
Cette approche nous permettra de découper notre SI en domaine fonctionnel, en accord avec le métier et de ces domaines nous bâtirons nos différents microservices !
Pour une vision plus complète du sujet, consulter : https://cdiese.fr/domain-driven-design-en-5-min/ (il vous faudra plus que 5min pour lire cet article !) et docs.microsoft.com.