Feature-Sliced Design: esența, metodologia împărțirii pe funcționalități

Ce este Feature-Sliced Design?

Feature-Sliced Design (FSD) — o metodologie de arhitectură a aplicațiilor frontend, propusă pentru prima dată în 2021 de comunitatea feature-sliced.design. Ideea principală a FSD — gruparea codului după funcționalități de business (slice-uri), fiecare fiind o unitate autosuficientă: conține propria logică de business, interfață cu utilizatorul, lucru cu API, modele de date și teste. Aceasta deosebește FSD de arhitectura clasică pe straturi, unde codul este împărțit după criterii tehnice (controller, service, repository).

Metodologia împrumută concepte din Domain-Driven Design (DDD) și Bounded Context: fiecare funcționalitate a aplicației este un bounded context separat cu granițe clare. Modificările în interiorul unei funcționalități nu ar trebui să strice alte funcționalități, dacă acestea folosesc doar API-ul public al slice-ului. Conform datelor sondajului State of Frontend 2024, FSD ocupă locul doi ca popularitate printre arhitecturile React (23%), cedând doar structurii informale Feature-based (31%).

În dezvoltarea mobilă, FSD se adaptează la specificul modulelor Android și framework-urilor iOS. În IT Sectr folosim FSD pentru proiecte cu 10+ ecrane și 3+ echipe — metodologia permite dezvoltarea independentă a funcționalităților și reduce numărul conflictelor în git cu 40% comparativ cu un monorepository fără granițe de slice-uri.

Șapte straturi FSD: structură și reguli de import

FSD definește șapte straturi ierarhice, fiecare conținând cod de un anumit nivel de abstractizare. Regula arhitecturală principală — straturile pot importa doar cod din straturile inferioare. Încălcarea acestei reguli (importul stratului features în entities) este considerată o eroare arhitecturală și este blocată de linter.

Exemplu de structură de directoare a unui proiect FSD:

src/
├── app/                    // Stratul aplicației
│   ├── providers/
│   ├── router/
│   └── styles/
├── pages/                   // Pagini — compoziția funcționalităților
│   └── main/
├── features/                // Funcționalități — scenarii de utilizator
│   ├── auth/                // Slice «Autentificare»
│   │   ├── ui/
│   │   ├── model/
│   │   └── api/
│   └── productList/         // Slice «Listă produse»
│       ├── ui/
│       └── model/
├── entities/                // Entități de business
│   ├── user/
│   └── product/
├── widgets/                 // Componente compoziționale
│   └── header/
└── shared/                  // Utilitare comune și UI-kit
    └── ui/

Regula „straturile privesc doar în jos" — piatra de temelie a FSD. Dacă funcționalitatea auth importă entitatea user — este corect. Dacă entitatea user începe să importe funcționalitatea auth — este o dependență ciclică și o încălcare a izolării. Pentru asigurarea respectării regulii, se folosesc pluginuri ESLint (eslint-plugin-fsd) sau lintere proprii ale API-ului public al slice-urilor.

Slice-uri: granițele domeniilor de business

Slice-ul — unitatea principală de grupare în FSD, corespunzând unei funcționalități de business sau entități. Fiecare slice se află în interiorul unuia dintre cele șapte straturi (features, entities, widgets, pages) și conține setul complet de cod pentru implementarea unei funcționalități concrete: componente UI, model de date, client API, constante și teste.

Granițele slice-urilor sunt determinate de domeniul de business: funcționalitatea auth include tot ce ține de autentificare (formular de autentificare, formular de înregistrare, resetare parolă); entitatea user include modelul User, UserRepository și serializarea. Granițele nu trebuie să se suprapună: dacă funcționalitatea auth are nevoie de date despre utilizator — importă entitatea user, nu copiază logica. În dezvoltarea mobilă, un slice FSD corespunde adesea unui modul Gradle în Android sau unui pachet Swift în iOS.

Slice-urile sunt strict izolate: structura internă a unui slice este invizibilă pentru alte slice-uri. Pentru interacțiunea între slice-uri se folosește API-ul public — fișierul index.ts/index.js care exportă doar ceea ce este permis pentru utilizare din exterior. Restul sunt module private. Această abordare previne dependențele accidentale și simplifică refactorizarea: modificarea implementării private a unui slice nu afectează alte slice-uri.

Segmente: UI, API, Model, Lib în interiorul unui slice

În interiorul fiecărui slice FSD, codul este organizat suplimentar pe segmente — categorii tehnice care se repetă în toate slice-urile. Setul standard de segmente include ui (componente de interfață), model (logică de business, Store, Actions, Reducer), api (cereri către server, mutații), lib (utilitare și helperi) și config (configurarea funcționalității).

Segmentele sunt o recomandare, nu o regulă strictă. Dacă slice-ul este mic, segmentele pot fi combinate. Pentru slice-uri mari (funcționalitate cu 10+ fișiere), segmentarea este obligatorie — fără ea, structura internă se transformă rapid într-un „coș" de 50 de fișiere, unde găsirea componentei necesare durează minute. În dezvoltarea mobilă, segmentele sunt adesea înlocuite cu o structură de fișiere pe tip: fiecare funcționalitate este un fișier Swift separat sau o clasă Kotlin cu tipuri interne.

FSD în dezvoltarea mobilă: adaptare pentru Android și iOS

În dezvoltarea mobilă, FSD se adaptează la particularitățile platformei — structura modulară Android (module Gradle) și Swift Package Manager. Adaptarea Android presupune că fiecare slice este un modul Gradle separat cu propriul build.gradle. Modulele feature-auth, feature-profile, entity-user, shared-ui sunt izolate între ele la nivel de compilare: feature-auth nu poate importa feature-profile dacă nu este specificat în dependencies.

Adaptarea iOS se bazează pe Swift Package Manager: fiecare slice este un pachet Swift cu API public. În proiectele TCA, slice-ul feature.auth conține propriul Reducer, Store, View și client API. Conform datelor Swift Community Survey 2024, 28% dintre proiectele iOS cu TCA folosesc o arhitectură pe slice-uri apropiată de FSD.

Principala problemă a adaptării mobile FSD — duplicarea stratului shared. În dezvoltarea mobilă, componentele UI (shared/ui) depind adesea de platformă (Android Views vs Jetpack Compose vs SwiftUI), ceea ce necesită module shared separate pentru fiecare tehnologie. În FSD, stratul shared este de obicei independent de platformă (utilitare, configuri), iar UI-kit este externalizat într-un modul separat sau o bibliotecă de componente.

Avantaje și dezavantaje ale Feature-Sliced Design

Avantajele FSD devin vizibile în proiecte mari cu 10+ dezvoltatori. Fiecare dezvoltator sau echipă se ocupă de propriul slice, fără a atinge codul altora. Conflictele în git se reduc cu 40–60% (date din case studies feature-sliced.design). Funcționalități noi sunt adăugate fără riscul de a strica existentele, dacă folosesc doar API-ul public al slice-urilor. Refactorizarea unei funcționalități nu necesită modificarea altora — este suficient să rescrii ui/model/api în interiorul unui singur slice, păstrând API-ul public.

Dezavantajele FSD — cuibărire excesivă pentru proiecte mici. Dacă aplicația constă din 3–5 ecrane, șapte straturi și segmentarea în interiorul fiecărui slice creează mai mult cod organizațional decât aplicația în sine. Pragul de intrare este ridicat: dezvoltatorii noi petrec 2–4 săptămâni pentru a însuși metodologia. De asemenea, FSD este slab compatibil cu prototiparea rapidă — prototipul necesită importuri frecvente cross-layer, care sunt interzise în FSD și încetinesc iterațiile.

Se recomandă începerea cu o structură Feature-based mai simplă și migrarea la FSD când numărul de ecrane depășește 20, iar echipa — 5 dezvoltatori.