La meilleure architecture frontale complexe : ce que vous devez savoir sur la conception découpée en fonctionnalités

Introduction

Les développeurs frontend sont souvent confrontés à un problème lié à l’architecture des applications. Cela nécessite l’utilisation d’une architecture qui peut facilement évoluer et fournir un couplage lâche et une cohésion élevée entre les modules d’application.

Cet article traite de l'architecture Feature-Sliced Design, car, à mon avis, c'est la meilleure parmi les options disponibles. Il explore également l'idée de FSD et les problèmes que cette méthodologie architecturale résout.

Nous comparerons FSD avec les architectures classiques et modulaires et examinerons leurs avantages et inconvénients.

Tout d’abord, distinguons trois concepts : layer, slice et segment.

Couches

Les couches sont des répertoires de niveau supérieur et le premier niveau de décomposition des applications. Ils sont en nombre limité – 7 couches maximum – et standardisés, même si certains d’entre eux sont facultatifs.

Actuellement, on distingue les couches suivantes :

Chaque couche a sa propre zone de responsabilité et est orientée métier. Considérons chaque couche séparément.

• app : c'est ici que la logique de l'application est initialisée. Les fournisseurs, routeurs, styles globaux, déclarations de type globales, etc. sont définis ici. Il sert de point d’entrée à l’application.

• processus : cette couche gère les processus qui s'étendent sur plusieurs pages, tels que l'enregistrement en plusieurs étapes. Cette couche est considérée comme obsolète mais peut encore être rencontrée occasionnellement. C'est une couche facultative.

• pages : Cette couche inclut les pages de l’application.

• widgets : ce sont des composants d'interface utilisateur autonomes utilisés sur les pages.

• fonctionnalités : cette couche traite des scénarios utilisateur et des fonctionnalités qui ont une valeur commerciale. Par exemple, j'aime, rédiger des critiques, noter des produits, etc. Il s'agit d'une couche facultative.

• entités : cette couche représente les entités commerciales. Ces entités peuvent inclure des utilisateurs, des avis, des commentaires, etc. Il s'agit d'une couche facultative.

• partagé : cette couche contient des composants et des utilitaires réutilisables qui ne sont pas liés à une logique métier spécifique. Il comprend un kit d'interface utilisateur, une configuration Axios, une configuration d'application, des aides qui ne sont pas liées à la logique métier, etc.

Ces couches aident à organiser la base de code et à promouvoir une architecture modulaire, maintenable et évolutive.

L’une des principales caractéristiques de Feature-Sliced Design est sa structure hiérarchique. Dans cette structure, les entités ne peuvent pas utiliser les fonctionnalités des fonctionnalités car celles-ci sont plus élevées dans la hiérarchie.

De même, les fonctionnalités ne peuvent pas utiliser de composants de widgets ou de processus, car les couches supérieures ne peuvent utiliser que les couches inférieures. Ceci est fait pour maintenir un flux linéaire dirigé dans une seule direction. Plus une couche est positionnée bas dans la hiérarchie, plus il est risqué d’y apporter des modifications puisqu’elle est susceptible d’être utilisée à plus d’endroits dans le code. Par exemple, le kit d'interface utilisateur de la couche partagée est utilisé dans les fonctionnalités, les widgets et même les couches de page.

Tranches

Dans chacune des couches se trouvent des sous-répertoires - les tranches - le deuxième niveau de décomposition des applications. Dans les tranches, le lien ne se fait pas avec des choses abstraites mais avec des entités commerciales spécifiques. L'objectif principal des tranches est de regrouper le code par sa valeur.

Les noms de tranches ne sont pas standardisés, car ils sont directement déterminés par le domaine d'activité du projet. Par exemple, dans une galerie de photos, il peut y avoir des sections telles que photo, album et galerie. Un réseau social nécessiterait des tranches telles que les publications, les utilisateurs et les fils d'actualité.

Les fragments étroitement liés peuvent être structurellement regroupés dans un répertoire, mais ils doivent respecter les mêmes règles d'isolement que les autres tranches - il ne doit pas y avoir d'accès partagé au code dans ce répertoire.

Segments

Chaque tranche est constituée de segments. Les segments aident à diviser le code au sein d'une tranche en fonction de son objectif. En fonction des accords de l'équipe, les segments peuvent changer de composition et de nom. Les segments suivants sont plus couramment utilisés :

• api - requêtes de serveur nécessaires.

• UI - Composants d'interface utilisateur de la tranche.

• modèle - Logique commerciale, c'est-à-dire interaction avec l'État. Par exemple, les actions et les sélecteurs.
• lib - fonctionnalité auxiliaire utilisée dans la tranche.

• config - configuration nécessaire de la tranche, mais le segment de configuration est rarement rencontré.

• consts - constantes nécessaires.

API publique

Chaque tranche et segment possède une API publique. L'API publique est représentée par un fichier index.js ou index.ts, qui permet d'extraire uniquement les fonctionnalités nécessaires de la tranche ou du segment vers l'extérieur et d'isoler les fonctionnalités inutiles. Le fichier d'index sert de point d'entrée.

Règles pour l'API publique :

• Les tranches et segments d'application utilisent uniquement les fonctionnalités et les composants de la tranche définis dans le fichier d'index de l'API publique.

• La partie interne de la tranche ou du segment qui n'est pas définie dans l'API publique est considérée comme isolée et ouverte uniquement à l'accès au sein de la tranche ou du segment lui-même.

L'API publique simplifie le travail d'importation et d'exportation. Ainsi, lors de la modification de l'application, il n'est pas nécessaire de modifier les importations partout dans le code.

Plus profondément dans l’architecture

Abstraction et logique métier

Plus la couche est élevée, plus elle est liée au nœud métier spécifique et plus elle contient de logique métier. Plus la couche est basse, plus il y a d'abstractions, de réutilisabilité et de manque d'autonomie dans la couche.

Comment FSD résout-il le problème ?

L’une des tâches de la conception en tranches de fonctionnalités est d’obtenir un couplage lâche et une cohésion élevée. Il est important de comprendre comment FSD parvient à ce résultat.

En POO, ces problèmes ont longtemps été résolus grâce à des concepts tels que le polymorphisme , l'encapsulation , l'héritage et l'abstraction . Ces concepts garantissent l'isolement, la réutilisabilité et la polyvalence du code, où différents résultats sont obtenus en fonction de la manière dont un composant ou une fonctionnalité est utilisé.

La conception par tranches de fonctionnalités permet d'appliquer ces principes dans le frontend.

L'abstraction et le polymorphisme sont obtenus grâce à des couches. Étant donné que les couches inférieures sont abstraites, elles peuvent être réutilisées dans des couches supérieures et, selon les conditions, un composant ou une fonctionnalité peut fonctionner différemment en fonction des paramètres ou des accessoires spécifiés.

L'encapsulation est réalisée via l'API publique, qui isole ce qui n'est pas nécessaire de l'extérieur dans des tranches et des segments. L'accès aux segments internes d'une tranche est restreint et l'API publique est le seul moyen d'accéder aux fonctionnalités et aux composants à partir d'une tranche ou d'un segment.

L'héritage s'effectue également via les couches, car les couches supérieures peuvent réutiliser les couches inférieures.

Comparaison avec l'architecture classique

Je crois que vous avez souvent rencontré l’architecture classique. La plupart des auteurs l'utilisent dans des articles pédagogiques et des vidéos YouTube en raison de sa simplicité. Il n'existe pas de norme spécifique pour l'architecture classique. Cependant, vous pouvez souvent voir le format suivant :

L'architecture classique présente des inconvénients notables. Le plus important est que le projet devient difficile à maintenir en raison des connexions implicites entre les composants et de l'encombrement des modules. Les inconvénients de l’architecture classique deviennent plus apparents avec le temps. Plus le projet évolue, plus l’architecture applicative devient un fouillis difficile à démêler.

L'architecture classique convient aux petits projets sans entretien continu ni projets favoris.

Feature-Sliced Design, grâce à ses concepts et standards, évite les problèmes de l’architecture classique.

Cependant, le niveau de compréhension et de compétences des développeurs travaillant avec FSD devrait être plus élevé que lorsqu'ils travaillent avec une architecture classique. Habituellement, les développeurs ayant moins de 2 ans d’expérience n’ont pas entendu parler de FSD.

Cependant, lorsque vous travaillez avec une conception par tranches de fonctionnalités, les problèmes doivent être résolus « maintenant » plutôt que « plus tard ». Les problèmes dans le code et les écarts par rapport aux concepts deviennent immédiatement apparents

Comparaison avec une architecture modulaire simple

Une architecture modulaire simple présente plusieurs inconvénients :

• Parfois, on ne sait pas exactement où placer les fonctionnalités dans les modules ou les composants.

• Difficultés à utiliser des modules dans un autre module.

• Problèmes liés au stockage des entités commerciales.

• Dépendances implicites dans les fonctions globales, conduisant à une structure enchevêtrée.

Il semble que dans tout projet complexe ou moyennement complexe, la conception par tranches de fonctionnalités devrait être préférée à une architecture modulaire simple. FSD résout de nombreux problèmes architecturaux fondamentaux et présente peu d'inconvénients.

En termes de simplicité et de rapidité de développement, une architecture modulaire simple peut présenter un avantage par rapport à FSD. Si un MVP est nécessaire ou si un projet de courte durée est en cours de développement, une architecture modulaire simple peut être plus adaptée que FSD. Mais dans tous les autres cas, une conception divisée en fonctionnalités semble préférable.

Le potentiel de la conception découpée en fonctionnalités

FSD est une jeune méthodologie architecturale. Cependant, il est déjà utilisé par de nombreuses sociétés bancaires, fintech, B2B, de commerce électronique et autres. Voici un lien vers le problème GitHub avec une liste d'entreprises : GitHub Issue .

Le référentiel GitHub avec la documentation officielle FSD comptait plus de 1,1 000 étoiles au moment de la publication de cet article. La documentation est activement développée et l'équipe de développement FSD et la communauté Telegram et Discord sont disponibles 24h/24 et 7j/7 pour aider les personnes ayant des questions liées à l'architecture.

Le potentiel de cette architecture est très apprécié et son utilisation est largement répandue parmi les grandes entreprises du monde entier. Avec une adoption appropriée, FSD a le potentiel de devenir la solution architecturale dominante dans le domaine du développement front-end.

Avantages et inconvénients de l'architecture

Avantages

• Les composants de l'architecture peuvent être facilement remplacés, ajoutés ou supprimés

• Standardisation de l'architecture

• Évolutivité

• La méthodologie est indépendante de la stack de développement.

• Connexions contrôlées et explicites entre les modules sans effets secondaires inattendus.

• Méthodologie architecturale orientée métier.

Désavantages

• Une barrière d’entrée plus élevée par rapport à de nombreuses autres solutions architecturales.

• Nécessite une sensibilisation, une culture d’équipe et le respect des concepts.

• Les défis et les problèmes doivent être résolus immédiatement, plutôt que plus tard. Les problèmes de code et les écarts par rapport aux concepts sont immédiatement visibles. Cependant, cela peut aussi être considéré comme un avantage.

Conclusion

Feature-Sliced Design est une découverte intéressante et précieuse que les développeurs frontend devraient connaître et pouvoir utiliser. FSD peut fournir aux équipes une architecture et une culture de développement flexibles, standardisées et évolutives. Cependant, l’utilisation des aspects positifs de la méthodologie nécessite des connaissances, une sensibilisation et de la discipline au sein de l’équipe.

FSD se distingue des autres architectures par son orientation commerciale claire, sa définition d'entité, sa composition fonctionnelle et la composition des composants de l'application.

Vous pouvez également explorer indépendamment des exemples d'utilisation de FSD dans des projets et la documentation officielle de Feature-Sliced Design :

Documentation officielle

Exemple. Client GitHub

Exemple. Magasin de baskets et de chaussures Nike

Exemple. Sudoku

Cet article est peut-être long, mais j'espère que vous avez appris quelque chose de nouveau. J'apprécie que vous ayez fini de lire cet article.

Si vous avez des idées ou des questions, n'hésitez pas à laisser un commentaire !

Également publié ici