Utilisation de l'analyse de domaine pour modéliser les microservices

L’un des plus grandes problématiques des microservices est la définition des limites de chacun des services isolés. La règle générale est qu’un service ne doit faire qu’une seule chose, mais mettre cette règle en pratique nécessite une réflexion minutieuse. Il n’y a pas de processus mécanique qui produit la conception correcte. Vous devez réfléchir profondément à votre domaine métier, aux exigences, aux caractéristiques d’architecture (également appelées exigences non fonctionnelles) et aux objectifs. Sinon, vous pouvez avoir à gérer une conception incohérente présentant des caractéristiques indésirables, comme des dépendances masquées entre les services, un couplage étroit ou des interfaces mal développées. Ce chapitre présente une approche orientée domaine de la conception des microservices. L’évaluation des limites des services est un effort continu sur les charges de travail en évolution. Parfois, l’évaluation entraîne des définitions redéfinies des limites existantes qui nécessitent davantage de développement d’applications pour prendre en charge les modifications.

Cet article utilise l'exemple d'un service de livraison par drone. Pour plus d’informations sur le scénario et l’implémentation de référence correspondante, consultez Concevoir une architecture de microservices.

Présentation

Les microservices doivent être conçus autour des capacités commerciales, pas autour de couches horizontales telles que l'accès aux données ou la messagerie. Par ailleurs, ils doivent présenter un couplage souple et une haute cohérence fonctionnelle. Les microservices sont couplés souplement si vous êtes en mesure de modifier un service sans avoir à mettre à jour d’autres services au même moment. Un microservice est cohérent s’il a une vocation unique et précisément définie, comme la gestion des comptes utilisateurs ou le suivi de l’historique de livraison. Un service a vocation à encapsuler la connaissance du domaine et à extraire cette connaissance des clients. Par exemple, un client doit pouvoir programmer un drone sans connaître en détail l’algorithme de programmation ni maîtriser la gestion de la flotte de drones. Les caractéristiques de l’architecture doivent être définies pour chaque microservice afin de correspondre à ses préoccupations de domaine, plutôt que d’être définies pour l’ensemble du système. Par exemple, un microservice côté client peut avoir besoin de performances, de disponibilité, de tolérance de panne, de sécurité, de testabilité et d’agilité. Un microservice back-end peut avoir besoin d’avoir uniquement une tolérance de panne et une sécurité. Si les microservices ont des communications synchrones entre eux, la dépendance entre eux produit souvent le besoin de partager les mêmes caractéristiques d’architecture.

La conception pilotée par le domaine (DDD) fournit un cadre qui permet d'atteindre en grande partie un ensemble bien conçu de microservices. Cette approche comporte deux phases distinctes, l’une stratégique, l’autre tactique. Dans le DDD stratégique, vous définissez la structure à grande échelle du système. L'approche DDD stratégique aide à garantir que votre architecture demeure axée sur les capacités commerciales. Le DDD tactique offre un ensemble de modèles de conception que vous pouvez utiliser pour créer le modèle de domaine. Ces modèles comprennent les entités, les agrégats et les services de domaine. Ces modèles tactiques vous aident à concevoir des microservices qui sont à la fois faiblement couplés et cohérents.

Dans cet article et dans le suivant, nous allons nous intéresser aux phases suivantes, en les exécutant avec l'application Drone Delivery :

1. Commencez par analyser le domaine d’entreprise afin d’appréhender les exigences fonctionnelles de l’application. Cette étape produit une description informelle du domaine, qui peut être affinée en un jeu plus formel de modèles de domaine.

2. Ensuite, définissez les limites de contexte du domaine. Chaque limite de contexte comporte un modèle de domaine représentant un sous-domaine spécifique de l’application dans son ensemble.

3. Au sein d’un contexte délimité, appliquez des modèles tactiques de la conception pilotée par domaine (DDD) afin de définir les entités, les agrégats et les services de domaine.

4. Utilisez les résultats de l’étape précédente pour identifier les microservices dans votre application.

Dans cet article, nous abordons les trois premières étapes, qui sont principalement liées à la conception pilotée par domaine (DDD). Dans l'article suivant, nous identifierons les microservices. Toutefois, il est essentiel de se rappeler que la DDD est un processus continu, itératif. Les limites de services ne sont pas fixes. À mesure qu’une application évolue, vous pouvez décider de séparer un service en plusieurs services plus petits.

Scénario : Livraison par drone

Fabrikam, Inc. veut lancer un service de livraison par drone. La société gère un parc de drones. Les entreprises souscrivent au service, et les utilisateurs peuvent demander à ce qu’un drone vienne récupérer les marchandises à livrer. Lorsqu’un client planifie un enlèvement de colis, un système principal assigne un drone et donne à l’utilisateur un délai de livraison estimé. Une fois la livraison en cours, le client peut suivre la position du drone, avec un ATE mis à jour en permanence.

Ce scénario comprend un domaine assez complexe. Certaines des principales préoccupations de l’entreprise incluent la planification des drones, le suivi des packages, la gestion des comptes d’utilisateur et le stockage et l’analyse des données historiques. Fabrikam a également pour objectif d’accéder rapidement au marché et d’itérer rapidement, en ajoutant de nouvelles fonctionnalités et capacités. L’application doit fonctionner à l’échelle du cloud et atteindre un objectif de niveau de service élevé. En outre, Fabrikam s’attend à ce que différentes parties du système aient des exigences variables pour le stockage et l’interrogation des données. Ces considérations amènent Fabrikam à adopter une architecture de microservices pour l’application Drone Delivery.

Analyser le domaine

Une approche DDD vous aide à concevoir des microservices afin que chaque service constitue un ajustement naturel à une exigence métier fonctionnelle. Cela peut vous aider à éviter le piège consistant à développer une conception dictée par les limites organisationnelles ou les choix technologiques.

Avant d’écrire du code, vous devez avoir une compréhension générale du système que vous générez. Le DDD commence par modéliser le domaine d'entreprise et créer un modèle de domaine. Le modèle de domaine est un modèle théorique du modèle d’entreprise. Il distille et organise les connaissances du domaine et fournit un langage commun aux développeurs et aux experts du domaine.

Commencez par mapper toutes les fonctions métier et leurs connexions. Cet effort peut être une collaboration qui comprend des experts du domaine, des architectes logiciels et d’autres parties prenantes. Il n’est pas nécessaire de recourir à aucun formalisme particulier. Dessinez un schéma ou établissez une esquisse sur tableau blanc.

Lorsque vous remplissez le diagramme, vous pouvez commencer à identifier les sous-domaines discrets. Quelles fonctions sont étroitement liées ? Quelles fonctions sont essentielles à l’entreprise et quelles fonctions fournissent des services auxiliaires ? Qu’est-ce que le graphique des dépendances ? Durant cette phase initiale, vous ne vous intéressez pas aux technologies ni aux détails de l’implémentation. Cela dit, vous devez noter l’endroit où l’application doit s’intégrer à des systèmes externes, tels que la gestion des relations client, le traitement des paiements ou les systèmes de facturation.

Exemple : Application de livraison par drone (Drone Delivery)

Après quelques activités d’analyse initiale de domaine, l’équipe Fabrikam est parvenue à établir une esquisse brute décrivant le domaine de l’application Drone Delivery.

• L'expédition est placée au centre du schéma, car elle est au cœur de l'activité. Tous les autres éléments du schéma existent pour permettre cette fonctionnalité.
• La Gestion des drones est également cruciale. Une fonctionnalité étroitement liée à la gestion des drones est la réparation des drones ; combinée à l’analyse prédictive, elle permet d’établir un échéancier des périodes d’entretien et de maintenance des drones.
• L’analyse de l'ETA fournit des estimations des horaires de ramassage et de livraison.
• Le modèle de transport tiers permet à l’application de planifier des modes de transport alternatifs en cas d’incapacité du drone à livrer l’intégralité d’un colis.
• Le partage de drones est une extension possible de l’activité principale. La société pourrait avoir une capacité de drone excédentaire pendant certaines heures et pourrait louer des drones qui seraient autrement inactifs. Cette fonctionnalité ne sera pas disponible dans la version initiale.
• La surveillance vidéo est un autre secteur que l’entreprise pourrait choisir de développer à l’avenir.
• Les comptes utilisateurs, la facturation et le centre d’appels sont des sous-domaines qui prennent en charge l’activité fondamentale.

Notez qu’à ce stade du processus, nous n’avons encore pris aucune décision ayant trait à l’implémentation ou aux technologies. Certains sous-systèmes peuvent impliquer des systèmes logiciels externes ou des services tiers. Même dans ce cas, l’application doit interagir avec ces systèmes et services. Aussi, il est important de les inclure dans le modèle de domaine.

Définir les limites de contexte

Le modèle de domaine comprend des représentations des composantes réelles (utilisateurs, drones, colis, etc.). Cela ne signifie pas pour autant que chacune des portions du système doive utiliser la même représentation pour une composante donnée.

Par exemple, les sous-systèmes qui gèrent la réparation des drones et l’analyse prédictive doivent représenter de nombreuses caractéristiques physiques des drones, telles que leur historique de maintenance, leur kilométrage, leur âge, leur numéro de modèle et leurs caractéristiques de performances. Toutefois, lors de la planification d’une livraison, ces éléments importent peu. Le sous-système de planification doit simplement connaître la disponibilité des drones, ainsi que les horaires prévus de collecte et de livraison.

Si nous essayions de développer un modèle unique pour chacun de ces sous-systèmes, cela pourrait s’avérer inutilement complexe. Par ailleurs, l’évolution au fil du temps du modèle serait ralentie, dans la mesure où les modifications devraient être validées par plusieurs équipes travaillant sur des sous-systèmes séparés. Par conséquent, il est souvent préférable de concevoir des modèles séparés qui représentent la même entité réelle (dans ce cas, un drone) dans deux contextes différents. Chaque modèle comporte les fonctions et attributs qui sont nécessaires au sein du contexte considéré.

Le concept DDD des contextes délimités entre en jeu ici. Un contexte limité définit la limite dans un domaine où un modèle de domaine spécifique s’applique. En faisant référence au diagramme précédent, vous pouvez regrouper des fonctionnalités en fonction de la façon dont différentes fonctions partagent le même modèle de domaine.

Les contextes délimités ne sont pas nécessairement isolés les uns des autres. Dans ce schéma, les lignes pleines reliant les limites de contexte représentent les points d’interaction entre deux limites de contexte. Par exemple, l’Expédition dépend des Comptes utilisateur au niveau de la collecte des informations sur les clients, et de la Gestion des drones en matière de sollicitation des drones disponibles de la flotte.

Dans son ouvrage Domain Driven Design (Conception pilotée par domaine), Eric Evans décrit plusieurs approches utilisées pour maintenir l’intégrité d’un modèle de domaine interagissant avec une autre limite de contexte. L’un des principes fondamentaux des microservices concerne la communication des services, qui s’effectue via des API précisément définies. Cette approche correspond à deux modèles que M. Evans appelle Open Host Service (Service hôte ouvert) et Published Language (Langage publié). L’idée derrière le Service hôte ouvert, c’est qu’un sous-système définit un protocole formel (API) valorisé par les autres sous-systèmes souhaitant communiquer avec lui. Le Langage publié développe cette idée en publiant l'API sous une forme que d'autres équipes peuvent utiliser pour écrire des clients. Dans l'article Conception d'API pour les microservices, nous évoquons l'utilisation de la Spécification OpenAPI (anciennement Swagger) afin de définir des descriptions d'interface indépendantes de tout langage pour les API REST, exprimées au format JSON ou YAML.

Pour le reste de cette activité, nous nous intéresserons à la limite de contexte Expédition.

Étapes suivantes

À l'issue de l'analyse d'un domaine, l'étape suivante consiste à appliquer la phase tactique de la conception pilotée par domaine pour définir vos modèles de domaine avec plus de précision.

Ressources associées

• Conception d’architecture de microservices
• Concevoir une architecture de microservices
• Identifier les limites des microservices
• Choisir une option de calcul Azure pour les microservices