Identification des limites du micro-frontend

Pour améliorer l'autonomie des équipes, les fonctionnalités métier fournies par une application peuvent être décomposées en plusieurs micro-frontends avec un minimum de dépendances les unes par rapport aux autres.

En suivant la méthodologie DDD évoquée précédemment, les équipes peuvent décomposer un domaine d'application en sous-domaines métiers et en contextes délimités. Les équipes autonomes peuvent alors s'approprier les fonctionnalités de leurs contextes délimités et fournir ces contextes sous forme de micro-frontends. Pour plus d'informations sur la séparation des préoccupations, consultez le diagramme Serverless Land.

Un contexte délimité bien défini devrait minimiser les chevauchements fonctionnels et la nécessité d'une communication d'exécution entre les contextes. La communication requise peut être mise en œuvre à l'aide de méthodes axées sur les événements. Cela n'est pas différent de l'architecture axée sur les événements pour le développement de microservices.

Une application bien conçue doit également prendre en charge la livraison des futures extensions par les nouvelles équipes afin d'offrir une expérience cohérente aux clients.

Comment découper une application monolithique en micro-frontends

La section Vue d'ensemble comprenait un exemple d'identification de contextes fonctionnels indépendants sur une page Web. Plusieurs modèles de division des fonctionnalités de l'interface utilisateur apparaissent.

Par exemple, lorsque les domaines commerciaux constituent les étapes d'un parcours utilisateur, une division verticale peut être appliquée sur le frontend, où un ensemble de vues du parcours utilisateur est diffusé sous forme de micro-interfaces. Le schéma suivant montre une division verticale, dans laquelle les étapes du catalogue, du paiement et de la facturation sont exécutées par des équipes distinctes sous la forme de micro-interfaces distinctes.

Pour certaines applications, la division verticale seule peut ne pas être suffisante. Par exemple, il peut être nécessaire de fournir certaines fonctionnalités dans de nombreuses vues. Pour ces applications, vous pouvez appliquer un fractionnement mixte. Le schéma suivant montre une solution mixte dans laquelle les micro-interfaces pour Station Finder et Route Explorer utilisent toutes deux la fonctionnalité d'affichage cartographique.

Les applications de type portail ou tableau de bord réunissent généralement les fonctionnalités du frontend dans une seule vue. Dans ces types d'applications, chaque widget peut être fourni sous forme de micro-frontend, et l'application d'hébergement définit les contraintes et les interfaces que les micro-frontends doivent implémenter.

Cette approche fournit un mécanisme permettant aux micro-frontends de gérer des problèmes tels que le dimensionnement de la fenêtre d'affichage, les fournisseurs d'authentification, les paramètres de configuration et les métadonnées. Ces types d'applications optimisent l'extensibilité. De nouvelles fonctionnalités peuvent être développées par de nouvelles équipes afin d'étendre les capacités du tableau de bord.

Le schéma suivant montre une application de tableau de bord développée par trois équipes individuelles faisant partie de Team Dashboard.

Dans le diagramme, la vue future représente les nouvelles fonctionnalités développées par les nouvelles équipes pour étendre le tableau de bord d'équipe et les fonctionnalités du tableau de bord.

Les applications de portail et de tableau de bord composent généralement les fonctionnalités en utilisant une répartition mixte dans l'interface utilisateur. Les micro-frontends sont configurables avec des paramètres bien définis, notamment des contraintes de position et de taille.