Cet article explique comment utiliser la conception pilotée par domaine (DDD) pour migrer une application monolithique vers des microservices.
Une application monolithique est généralement un système d’applications dans lequel tous les modules pertinents sont regroupés sous la forme d’une seule unité déployable d’exécution. Par exemple, il peut s’agir d’une application Web Java (WAR) s’exécutant sur Tomcat ou d’une application ASP.NET s’exécutant sur IIS. Une application monolithique classique utilise une conception en couches, avec des couches distinctes pour l’interface utilisateur, la logique d’application et l’accès aux données.
Ces systèmes commencent petit mais ont tendance à croître au fil du temps pour répondre aux besoins de l’entreprise. À un moment donné, à mesure que de nouvelles fonctionnalités sont ajoutées, une application monolithique peut commencer à subir les problèmes suivants :
- Les différentes parties du système ne peuvent pas être mises à l’échelle indépendamment, car elles sont étroitement couplées.
- Il est difficile d’assurer la mise à jour du code, en raison d’un couplage étroit et de dépendances masquées.
- Les procédures de test deviennent plus difficiles, ce qui augmente la probabilité d’introduire des vulnérabilités.
Ces problèmes peuvent devenir un obstacle à la croissance et à la stabilité futures. Les équipes hésitent à effectuer des modifications, en particulier si les développeurs d’origine ne travaillent plus sur le projet et que les documents de conception sont lacunaires ou obsolètes.
Malgré ces limitations, une conception monolithique peut avoir du sens comme point de départ pour une application. Les monolithes sont souvent le chemin le plus rapide pour créer une preuve de concept ou un produit viable minimal. Dans les premières phases du développement, les monolithiques ont tendance à être :
- Plus faciles à générer, car il existe une seule base de code partagé.
- Plus faciles à déboguer, car le code s’exécute au sein d’un processus et un espace mémoire uniques.
- Plus faciles à comprendre, car il y a moins de parties mobiles.
Toutefois, au fur et à mesure que l’application croît en complexité, ces avantages peuvent disparaître. Les monolithes de grande taille sont souvent plus difficiles à générer, déboguer et comprendre. À un moment donné, les problèmes l’emportent sur les avantages. C’est là qu’il peut être judicieux de migrer l’application vers une architecture de microservices. Contrairement aux monolithes, les microservices sont généralement des unités d’exécution décentralisées et faiblement couplées. Le diagramme suivant illustre une architecture de microservices classique :
La migration d’un monolithe vers un microservice nécessite un temps et un investissement significatifs pour éviter les défaillances ou les dépassements. Pour garantir la réussite de la migration, il est judicieux de comprendre les avantages et les défis que posent les microservices. Voici les avantages :
- Les services peuvent évoluer indépendamment en fonction des besoins des utilisateurs.
- Les services peuvent être mis à l’échelle indépendamment pour répondre à la demande de l’utilisateur.
- Au fil du temps, les cycles de développement sont plus rapides, car les fonctionnalités peuvent être mises en production plus rapidement.
- Les services sont isolés et sont plus tolérants aux défaillances.
- Un service unique qui échoue n’entraîne pas la défaillance de l’ensemble de l’application.
- Les tests deviennent plus cohérents grâce au développement piloté par le comportement.
Pour plus d’informations sur les avantages et les défis liés aux microservices, consultez Style d’architecture de microservices.
Appliquer la conception pilotée par domaine
Toute stratégie de migration doit permettre aux équipes de refactoriser de manière incrémentielle l’application en services plus petits, tout en assurant la continuité du service aux utilisateurs finaux. Voici l’approche générale :
- Arrêtez d’ajouter des fonctionnalités au monolithe.
- Séparez le serveur frontal du back end.
- Décomposez et découplez le monolithe en une série de microservices.
Pour faciliter cette décomposition, une approche viable de développement de logiciels consiste à appliquer les principes de la conception pilotée par domaine (DDD).
La conception pilotée par domaine (DDD) est une approche de développement de logiciels introduite par Eric Evans. DDD s’oppose à l’idée d’avoir un modèle unique et unifié pour l’ensemble du système. Au lieu de cela, il encourage à diviser le système en contextes délimités, chacun ayant son propre modèle. DDD nécessite une bonne compréhension du domaine pour lequel l’application sera écrite. Les connaissances de domaine nécessaires pour créer l’application appartiennent aux personnes qui les comprennent, c’est-à-dire les experts du domaine.
L’approche DDD peut être appliquée rétroactivement à une application existante, afin de commencer à décomposer l’application.
Commencez avec un langage omniprésent, un vocabulaire commun qui est partagé entre toutes les parties prenantes.
Identifiez les modules appropriés dans l’application monolithique et appliquez-leur le vocabulaire commun.
Définissez les modèles de domaine de l’application monolithique. Le modèle de domaine est un modèle théorique du modèle d’entreprise.
Définissez des limites de contexte pour les modèles. Une limite de contexte correspond au périmètre, au sein d’un domaine, dans lequel s’applique un modèle de domaine particulier. Appliquez des limites explicites avec des modèles et responsabilités clairement définis.
Les limites de contextes identifiés à l’étape 4 sont des candidats à la refactorisation en microservices plus petits. Le diagramme suivant montre le monolithe existant avec les limites de contextes :
Pour plus d’informations sur l’utilisation d’une approche DDD pour les architectures de microservices, consultez Utilisation de l’analyse de domaine pour modeler des microservices.
Utiliser du code de collage (couche de lutte contre la corruption)
Bien que ce travail d’investigation soit effectué pour inventorier l’application monolithique, de nouvelles fonctionnalités peuvent être ajoutées en appliquant les principes du DDD en tant que services distincts. Le code de collage permet à l’application monolithique de proxyser des appels au nouveau service pour obtenir de nouvelles fonctionnalités.
Le code de collage (modèle d’adaptateur) agit efficacement comme une couche anti-corruption, garantissant ainsi que le nouveau service n’est pas pollué par les modèles de données requis par l’application monolithique. Le code de collage permet de modérer les interactions entre les deux et de s’assurer que seules les données requises par le nouveau service sont transmises à des fins de compatibilité.
Par le biais du processus de refactorisation, les équipes peuvent inventorier l’application monolithique et identifier les candidats à la refactorisation des microservices tout en mettant en place de nouvelles fonctionnalités avec de nouveaux services.
Pour plus d’informations sur les couches de lutte contre la corruption, consultez Modèle de couche de lutte contre la corruption.
Créer une couche de présentation
L’étape suivante consiste à séparer la couche de présentation de la couche backend. Dans une application multiniveau classique, la couche d’application (métier) tend à être les composants qui sont essentiels à l’application et qui possèdent une logique de domaine. Ces API à granularité grossière interagissent avec la couche d’accès aux données pour récupérer les données persistantes à partir d’une base de données. Ces API établissent une limite naturelle à la couche de présentation et aident à découpler la couche de présentation dans un espace d’application distinct.
Le diagramme suivant illustre la couche de présentation (IU), séparée des couches de logique d’application et d’accès aux données.
Ce diagramme introduit également une autre couche, la passerelle API, qui se situe entre la couche de présentation et la logique d’application. La passerelle API est une couche de façade qui fournit une interface cohérente et uniforme avec laquelle la couche de présentation peut interagir, tout en permettant aux services en aval d’évoluer indépendamment, sans affecter l’application. La passerelle API peut utiliser une technologie telle que Azure API Management, et permet à l’application d’interagir de manière RESTful.
La couche de présentation peut être développée dans n’importe quel langage ou infrastructure pour lequel l’équipe a des compétences, par exemple une application à page unique ou une application MVC. Ces applications interagissent avec les microservices via la passerelle, à l’aide d’appels HTTP standard. Pour plus d’informations sur les passerelles API, consultez Utilisation de passerelles API dans les microservices.
Commencer à mettre hors service le monolithe
À ce stade, l’équipe peut commencer à détacher l’application monolithique et à extraire lentement les services qui ont été établis par leurs limites de contextes dans leur propre ensemble de microservices. Les microservices peuvent exposer une interface RESTful avec laquelle la couche d’application peut interagir, via la passerelle API, avec le code de collage en place pour communiquer avec le monolithe dans des circonstances spécifiques.
À mesure que vous continuez à détacher le monolithe, vous arrivez à un moment où son existence n’est plus pertinente et les microservices ont été correctement extraits du monolithe. À ce stade, la couche de lutte contre la corruption (code de collage) peut être supprimée en toute sécurité.
Cette approche est un exemple du modèle Figuier étrangleur et permet une décomposition contrôlée d’un monolithe en un ensemble de microservices. Au fil du temps, à mesure que les fonctionnalités existantes sont déplacées vers des microservices, la taille et la complexité du monolithe sont réduites, jusqu’à ce qu’il n’existe plus.
Contributeurs
Cet article est géré par Microsoft. Il a été écrit à l’origine par les contributeurs suivants.
Auteur principal :
- Lavan Nallainathan | Architecte de solution cloud senior
Pour afficher les profils LinkedIn non publics, connectez-vous à LinkedIn.
Étapes suivantes
Lorsque l’application a été décomposée en microservices constitutifs, il devient possible d’utiliser des outils d’orchestration modernes tels qu’Azure DevOps pour gérer le cycle de vie de chaque service. Pour plus d'informations, consultez Intégration continue/livraison continue (CI/CD) pour les architectures de microservices.