Concepts fondamentaux

L'architecture du micro-frontend est fortement inspirée de trois concepts architecturaux antérieurs :

• La conception axée sur le domaine est le modèle mental permettant de structurer des applications complexes en domaines cohérents.

• Les systèmes distribués constituent une approche permettant de créer des applications sous la forme de sous-systèmes faiblement couplés, développés indépendamment et exécutés sur leur propre infrastructure dédiée.

• Le cloud computing est une approche permettant de gérer une infrastructure informatique sous forme de services avec un pay-as-you-go modèle.

Conception axée sur le domaine

Le design piloté par domaine (DDD) est un paradigme développé par Eric Evans. Dans son livre de 2003 intitulé Domain-Driven Design : Tackling Complexity in the Heart of Software, Evans postule que le développement de logiciels doit être guidé par des préoccupations commerciales plutôt que par des préoccupations techniques. Evans propose que les projets informatiques développent d'abord un langage omniprésent qui aide les experts techniques et spécialisés à trouver une compréhension commune. Sur la base de ce langage, ils peuvent formuler un modèle mutuellement compréhensible de la réalité commerciale.

Aussi évidente que puisse être cette approche, de nombreux projets logiciels souffrent d'un décalage entre l'entreprise et l'informatique. Ces déconnexions sont souvent à l'origine de malentendus importants, qui se traduisent par des dépassements de budget, une baisse de la qualité ou l'échec du projet.

Evans introduit plusieurs autres termes importants, dont le contexte limité. Un contexte limité est un segment autonome d'une application informatique de grande envergure contenant la solution ou la mise en œuvre répondant exactement à un problème commercial. Une application de grande envergure sera composée de plusieurs contextes délimités qui sont faiblement couplés par le biais de modèles d'intégration. Ces contextes délimités peuvent même avoir leurs propres dialectes de la langue omniprésente. Par exemple, un utilisateur dans le contexte du paiement d'une application peut avoir des aspects différents de ceux d'un utilisateur dans le contexte de la livraison, car la notion d'expédition ne serait pas pertinente lors du paiement.

Evans ne définit pas la taille ou la taille d'un contexte délimité. La taille est déterminée par le projet logiciel et peut évoluer au fil du temps. Les bons indicateurs des limites d'un contexte sont le degré de cohésion entre les entités (objets du domaine) et la logique métier.

Dans le contexte des micro-frontends, la conception axée sur le domaine peut être illustrée par l'exemple d'une page Web complexe telle qu'une page de réservation de vol.

Sur cette page, les principaux éléments de base sont un formulaire de recherche, un panneau de filtres et la liste des résultats. Pour identifier les limites, vous devez identifier des contextes fonctionnels indépendants. Tenez également compte des aspects non fonctionnels, tels que la réutilisabilité, les performances et la sécurité. L'indicateur le plus important des « choses qui vont de pair » est leur mode de communication. Si certains éléments d'une architecture doivent communiquer fréquemment et échanger des informations complexes, ils partagent probablement le même contexte limité.

Les éléments individuels de l'interface utilisateur tels que les boutons ne sont pas des contextes limités, car ils ne sont pas indépendants du point de vue fonctionnel. De plus, la page entière ne convient pas à un contexte limité, car elle peut être décomposée en contextes indépendants plus petits. Une approche raisonnable consiste à traiter le formulaire de recherche comme un contexte limité et à traiter la liste des résultats comme le second contexte délimité. Chacun de ces deux contextes délimités peut désormais être implémenté en tant que micro-frontend distinct.

Systèmes distribués

Pour faciliter la maintenance et favoriser la capacité d'évolution, la majorité des solutions informatiques non triviales sont modulaires. Dans ce cas, la modularité signifie que les systèmes informatiques sont constitués d'éléments de base identifiables qui sont découplés par des interfaces afin de séparer les préoccupations.

En plus d'être modulaires, les systèmes distribués doivent être des systèmes indépendants à part entière. Dans un système simplement modulaire, chaque module est parfaitement encapsulé et expose ses fonctions par le biais d'interfaces, mais il ne peut pas être déployé indépendamment ni même fonctionner seul. De plus, les modules suivent généralement le même cycle de vie que les autres modules faisant partie du même système. Les éléments constitutifs d'un système distribué, en revanche, ont chacun leur propre cycle de vie. En appliquant le paradigme de conception axé sur le domaine, chaque élément de base concerne un domaine ou un sous-domaine commercial et vit dans son propre contexte délimité.

Lorsque les systèmes distribués interagissent pendant la phase de construction, une approche courante consiste à développer des mécanismes permettant d'identifier rapidement les problèmes. Par exemple, vous pourriez adopter des langages dactylographiés et investir massivement dans les tests unitaires. Plusieurs équipes peuvent collaborer au développement et à la maintenance de modules, souvent distribués sous forme de bibliothèques que les systèmes peuvent utiliser avec des outils tels que npm, Apache Maven et NuGet pip.

Pendant l'exécution, les systèmes distribués en interaction sont généralement détenus par des équipes individuelles. La consommation de dépendances entraîne une complexité opérationnelle en raison de la gestion des erreurs, de l'équilibrage des performances et de la sécurité. Les investissements dans les tests d'intégration et l'observabilité sont essentiels pour réduire les risques.

Les exemples les plus populaires de systèmes distribués aujourd'hui sont les microservices. Dans les architectures de microservices, les services principaux sont pilotés par le domaine (plutôt que par des problèmes techniques tels que l'interface utilisateur ou l'authentification) et détenus par des équipes autonomes. Les micro-frontends partagent les mêmes principes, étendant la portée de la solution au frontend.

L'informatique en nuage

Le cloud computing est un moyen d'acheter une infrastructure informatique sous forme de services avec un pay-as-you-go modèle au lieu de créer vos propres centres de données et d'acheter du matériel pour les faire fonctionner sur site. Le cloud computing présente plusieurs avantages :

• Votre entreprise gagne en agilité commerciale en étant en mesure d'expérimenter de nouvelles technologies sans avoir à prendre des engagements financiers importants et à long terme dès le départ.

• En faisant appel à un fournisseur de cloud tel que AWS, votre entreprise peut accéder à un large portefeuille de services nécessitant peu de maintenance et hautement intégrables (tels que des passerelles d'API, des bases de données, l'orchestration de conteneurs et des fonctionnalités cloud). L'accès à ces services permet à votre personnel de se concentrer sur le travail qui différencie votre organisation de la concurrence.

• Lorsque votre entreprise est prête à déployer une solution à l'échelle mondiale, vous pouvez la déployer sur l'infrastructure cloud du monde entier.

Le cloud computing prend en charge les micro-frontends en fournissant une infrastructure hautement gérée. Cela facilite end-to-end la prise en main par les équipes interfonctionnelles. Bien que l'équipe doive posséder de solides connaissances opérationnelles, les tâches manuelles liées au provisionnement de l'infrastructure, aux mises à jour du système d'exploitation et à la mise en réseau seraient une distraction.

Les micro-frontends évoluant dans des contextes limités, les équipes peuvent choisir le service le plus approprié pour les exécuter. Par exemple, les équipes peuvent choisir entre des fonctions cloud et des conteneurs pour le calcul, et elles peuvent choisir entre différentes versions de bases de données SQL et NoSQL ou de caches en mémoire. Les équipes peuvent même créer leurs micro-frontends sur une boîte à outils hautement intégrée AWS Amplify, telle que celle fournie avec des blocs de construction préconfigurés pour une infrastructure sans serveur.