Feature-Sliced Design : essence et méthodologie de division par features

Qu'est-ce que Feature-Sliced Design ?

Feature-Sliced Design (FSD) est une méthodologie d'architecture d'applications frontend proposée pour la première fois en 2021 par la communauté feature-sliced.design. L'idée centrale de FSD est de regrouper le code par fonctionnalités métier (slices), chacune étant une unité autonome : elle contient sa propre logique métier, interface utilisateur, interaction API, modèles de données et tests. Cela distingue FSD de l'architecture classique en couches où le code est divisé par critères techniques (controller, service, repository).

La méthodologie emprunte des concepts du Domain-Driven Design (DDD) et du Bounded Context : chaque feature de l'application est un bounded context séparé avec des limites claires. Les modifications à l'intérieur d'une feature ne doivent pas casser d'autres features si elles utilisent uniquement l'API publique du slice. Selon l'enquête State of Frontend 2024, FSD occupe la deuxième place en popularité parmi les architectures React (23%), juste derrière la structure informelle Feature-based (31%).

Dans le développement mobile, FSD s'adapte aux spécificités des modules Android et des frameworks iOS. Chez IT Sectr, nous utilisons FSD pour les projets avec 10+ écrans et 3+ équipes — la méthodologie permet de développer les features indépendamment et réduit les conflits git de 40% par rapport à un monorepo sans limites de slices.

Sept couches de FSD : structure et règles d'importation

FSD définit sept couches hiérarchiques, chacune contenant du code d'un certain niveau d'abstraction. La règle architecturale principale est que les couches ne peuvent importer que du code provenant de couches inférieures. Violer cette règle (importer la couche features dans entities) est considéré comme une erreur architecturale et est bloqué par un linter.

Exemple de structure de répertoire d'un projet FSD :

src/
├── app/                    // Couche application
│   ├── providers/
│   ├── router/
│   └── styles/
├── pages/                   // Pages — composition de features
│   └── main/
├── features/                // Features — scénarios utilisateur
│   ├── auth/                // Slice « Authentification »
│   │   ├── ui/
│   │   ├── model/
│   │   └── api/
│   └── productList/         // Slice « Liste de produits »
│       ├── ui/
│       └── model/
├── entities/                // Entités métier
│   ├── user/
│   └── product/
├── widgets/                 // Composants composites
│   └── header/
└── shared/                  // Utilitaires partagés et UI-kit
    └── ui/

La règle « les couches regardent uniquement vers le bas » est la pierre angulaire de FSD. Si feature auth importe entity user — c'est correct. Si entity user commence à importer feature auth — c'est une dépendance cyclique et une violation de l'isolation. Pour garantir cette règle, des plugins ESLint (eslint-plugin-fsd) ou des linters personnalisés de l'API publique des slices sont utilisés.

Slices : limites des domaines métier

Slice — l'unité principale de regroupement dans FSD, correspondant à une feature ou entité métier. Chaque slice réside dans l'une des sept couches (features, entities, widgets, pages) et contient un ensemble complet de code pour implémenter une fonctionnalité spécifique : composants UI, modèle de données, client API, constantes et tests.

Les limites des slices sont définies par le domaine métier : feature auth inclut tout ce qui concerne l'autorisation (formulaire de connexion, formulaire d'inscription, réinitialisation de mot de passe) ; entity user inclut le modèle User, UserRepository et la sérialisation. Les limites ne doivent pas se chevaucher : si feature auth a besoin de données utilisateur — il importe entity user plutôt que de dupliquer la logique. Dans le développement mobile, un slice FSD correspond souvent à un module Gradle dans Android ou un package Swift dans iOS.

Les slices sont strictement isolés : la structure interne d'un slice est invisible pour les autres slices. Pour l'interaction entre slices, une API publique est utilisée — un fichier index.ts/index.js qui exporte uniquement ce qui est autorisé à l'utilisation externe. Tout le reste sont des modules privés. Cette approche empêche les dépendances accidentelles et simplifie le refactoring : modifier l'implémentation privée d'un slice n'affecte pas les autres slices.

Segments : UI, API, Model, Lib à l'intérieur d'un slice

À l'intérieur de chaque slice FSD, le code est en outre organisé par segments — des catégories techniques qui se répètent dans tous les slices. L'ensemble standard de segments inclut ui (composants d'interface), model (logique métier, Store, Actions, Reducer), api (requêtes serveur, mutations), lib (utilitaires et helpers) et config (configuration de la feature).

Les segments sont une recommandation, pas une règle stricte. Si un slice est petit, les segments peuvent être fusionnés. Pour les grands slices (une feature avec 10+ fichiers), la segmentation est obligatoire — sans elle, la structure interne se transforme rapidement en un « panier » de 50 fichiers où trouver le composant nécessaire prend des minutes. Dans le développement mobile, les segments sont souvent remplacés par une structure de fichiers par type : chaque feature est un fichier Swift séparé ou une classe Kotlin avec des types internes.

FSD dans le développement mobile : adaptation pour Android et iOS

Dans le développement mobile, FSD s'adapte aux caractéristiques spécifiques de la plateforme — la structure modulaire d'Android (modules Gradle) et Swift Package Manager. Adaptation Android suppose que chaque slice est un module Gradle séparé avec son propre build.gradle. Les modules feature-auth, feature-profile, entity-user, shared-ui sont isolés les uns des autres au niveau de la compilation : feature-auth ne peut pas importer feature-profile à moins d'être spécifié dans dependencies.

Adaptation iOS est construite sur Swift Package Manager : chaque slice est un package Swift avec une API publique. Dans les projets TCA, le slice feature.auth contient son propre Reducer, Store, View et client API. Selon la Swift Community Survey 2024, 28% des projets iOS avec TCA utilisent une architecture de slices proche de FSD.

Le principal problème de l'adaptation mobile de FSD est la duplication de la couche shared. Dans le développement mobile, les composants UI (shared/ui) dépendent souvent de la plateforme (Android Views vs Jetpack Compose vs SwiftUI), ce qui nécessite des modules shared séparés pour chaque technologie. Dans FSD, la couche shared est généralement indépendante de la plateforme (utilitaires, configurations), tandis que l'UI-kit est déplacé vers un module séparé ou une bibliothèque de composants.

Avantages et inconvénients de Feature-Sliced Design

Avantages de FSD deviennent notables dans les grands projets avec 10+ développeurs. Chaque développeur ou équipe travaille sur son propre slice sans toucher au code des autres. Les conflits git sont réduits de 40 à 60% (données des études de cas feature-sliced.design). Les nouvelles features sont ajoutées sans risque de casser les existantes, à condition qu'elles utilisent uniquement l'API publique des slices. Refactoriser une feature ne nécessite pas de modifications dans les autres — il suffit de réécrire ui/model/api à l'intérieur d'un slice tout en conservant l'API publique.

Inconvénients de FSD — imbrication excessive pour les petits projets. Si une application se compose de 3 à 5 écrans, sept couches et la segmentation à l'intérieur de chaque slice créent plus de code d'organisation que l'application elle-même. La barrière à l'entrée est élevée : les nouveaux développeurs passent 2 à 4 semaines à apprendre la méthodologie. De plus, FSD est peu compatible avec le prototypage rapide — le prototypage nécessite des importations fréquentes entre couches, qui sont interdites dans FSD et ralentissent les itérations.

Il est recommandé de commencer par une structure Feature-based plus simple et de migrer vers FSD lorsque le nombre d'écrans dépasse 20 et que l'équipe dépasse 5 développeurs.