Feature-Sliced Design: esensya, metodolohiya ng paghahati sa mga feature

Ano ang Feature-Sliced Design?

Feature-Sliced Design (FSD) — isang metodolohiya ng arkitektura ng frontend application, unang iminungkahi noong 2021 ng komunidad ng feature-sliced.design. Ang pangunahing ideya ng FSD — pagpapangkat ng code ayon sa mga business feature (slices), bawat isa ay isang self-sufficient unit: naglalaman ng sarili nitong business logic, user interface, pagtatrabaho sa API, data models at tests. Ito ang nagpapahiwalay sa FSD mula sa klasikong layered na arkitektura, kung saan ang code ay hinati ayon sa teknikal na criterion (controller, service, repository).

Ang metodolohiya ay humihiram ng mga konsepto mula sa Domain-Driven Design (DDD) at Bounded Context: bawat feature ng application ay isang hiwalay na bounded context na may malinaw na hangganan. Ang mga pagbabago sa loob ng isang feature ay hindi dapat makasira ng ibang feature kung gumagamit lamang sila ng pampublikong API ng slice. Ayon sa datos ng State of Frontend 2024 survey, ang FSD ay nasa pangalawang pwesto sa kasikatan sa mga arkitektura ng React (23%), pumapangalawa lamang sa impormal na Feature-based na istraktura (31%).

Sa mobile development, ang FSD ay iniaangkop sa mga katangian ng Android modules at iOS frameworks. Sa IT Sectr ginagamit namin ang FSD para sa mga proyektong may 10+ screens at 3+ teams — pinapayagan ng metodolohiya ang independiyenteng pag-develop ng mga feature at binabawasan ang bilang ng mga conflict sa git ng 40% kumpara sa monorepository na walang hangganan ng slices.

Pitong layers ng FSD: istraktura at panuntunan sa import

Ang FSD ay tumutukoy sa pitong hierarchical layers, bawat isa ay naglalaman ng code ng isang tiyak na antas ng abstraction. Ang pangunahing panuntunan ng arkitektura — ang mga layer ay maaari lamang mag-import ng code mula sa mas mababang layers. Ang paglabag sa panuntunang ito (import ng features layer sa entities) ay itinuturing na isang arkitektural na error at hinahadlangan ng linter.

Halimbawa ng istraktura ng direktoryo ng FSD project:

src/
├── app/                    // Layer ng application
│   ├── providers/
│   ├── router/
│   └── styles/
├── pages/                   // Mga pahina — komposisyon ng features
│   └── main/
├── features/                // Features — mga scenario ng user
│   ├── auth/                // Slice ng pagpapatotoo
│   │   ├── ui/
│   │   ├── model/
│   │   └── api/
│   └── productList/         // Slice ng listahan ng produkto
│       ├── ui/
│       └── model/
├── entities/                // Mga business entity
│   ├── user/
│   └── product/
├── widgets/                 // Mga komposisyonal na component
│   └── header/
└── shared/                  // Mga pangkalahatang utility at UI-kit
    └── ui/

Ang panuntunang ang mga layer ay tumitingin lamang pababa — ang pundasyon ng FSD. Kung ang feature auth ay nag-i-import ng entity user — ito ay tama. Kung ang entity user ay magsisimulang mag-import ng feature auth — ito ay isang cyclic dependency at paglabag sa paghihiwalay. Upang masiguro ang pagsunod sa panuntunan, ginagamit ang ESLint plugins (eslint-plugin-fsd) o sariling linters ng pampublikong API ng slices.

Slices: hangganan ng mga business domain

Slice — ang pangunahing unit ng pagpapangkat sa FSD, na katumbas ng isang business feature o entity. Bawat slice ay nasa loob ng isa sa pitong layers (features, entities, widgets, pages) at naglalaman ng kumpletong set ng code para sa pagpapatupad ng isang tiyak na functionality: UI components, data model, API client, constants at tests.

Ang hangganan ng slices ay tinutukoy ng business domain: ang feature auth ay sumasaklaw sa lahat ng nauugnay sa pagpapatotoo (login form, registration form, reset password); ang entity user ay sumasaklaw sa User model, UserRepository at serialization. Ang hangganan ay hindi dapat magsanib: kung ang feature auth ay nangangailangan ng data tungkol sa user — ito ay nag-i-import ng entity user, hindi kinokopya ang logic. Sa mobile development, ang FSD slice ay madalas na katumbas ng Gradle module sa Android o Swift package sa iOS.

Ang slices ay mahigpit na nakahiwalay: ang panloob na istraktura ng isang slice ay hindi nakikita ng ibang slices. Para sa interaksyon sa pagitan ng slices, ginagamit ang pampublikong API — ang file na index.ts/index.js na nag-e-export lamang ng pinapayagang gamitin mula sa labas. Lahat ng iba ay pribadong modules. Ang approach na ito ay pumipigil sa aksidenteng dependencies at pinapasimple ang refactoring: ang pagbabago ng pribadong implementasyon ng isang slice ay hindi nakakaapekto sa ibang slices.

Mga Segment: UI, API, Model, Lib sa loob ng slice

Sa loob ng bawat FSD slice, ang code ay karagdagang inaayos ayon sa segments — teknikal na kategorya na nauulit sa lahat ng slices. Ang karaniwang set ng segments ay may kasamang ui (interface components), model (business logic, Store, Actions, Reducer), api (mga request sa server, mutations), lib (mga utility at helper) at config (configuration ng feature).

Ang segments ay rekomendasyon, hindi mahigpit na panuntunan. Kung maliit ang slice, ang segments ay maaaring pagsamahin. Para sa malalaking slices (feature na may 10+ files), ang segmentation ay sapilitan — kung wala ito ang panloob na istraktura ay mabilis na nagiging basket na may 50 files, kung saan ang paghahanap ng kinakailangang component ay tumatagal ng ilang minuto. Sa mobile development, ang segments ay madalas na pinapalitan ng file structure ayon sa uri: bawat feature ay isang hiwalay na Swift file o Kotlin class na may panloob na types.

FSD sa mobile development: adaptasyon para sa Android at iOS

Sa mobile development, ang FSD ay iniaangkop sa mga katangian ng platform — modular na istraktura ng Android (Gradle modules) at Swift Package Manager. Android adaptasyon ay nagpapalagay na ang bawat slice ay isang hiwalay na Gradle module na may sariling build.gradle. Ang mga module na feature-auth, feature-profile, entity-user, shared-ui ay nahiwalay sa isa't isa sa antas ng compilation: ang feature-auth ay hindi maaaring mag-import ng feature-profile kung hindi ito tinukoy sa dependencies.

iOS adaptasyon ay batay sa Swift Package Manager: bawat slice ay isang Swift package na may pampublikong API. Sa TCA projects, ang slice feature.auth ay naglalaman ng sarili nitong Reducer, Store, View at API client. Ayon sa Swift Community Survey 2024, 28% ng iOS projects na may TCA ay gumagamit ng slice architecture na malapit sa FSD.

Ang pangunahing problema ng mobile FSD adaptasyon — pagdodoble ng shared layer. Sa mobile development, ang UI components (shared/ui) ay madalas na nakadepende sa platform (Android Views vs Jetpack Compose vs SwiftUI), na nangangailangan ng hiwalay na shared modules para sa bawat teknolohiya. Sa FSD, ang shared layer ay karaniwang independiyente sa platform (mga utility, configuration), at ang UI-kit ay inilalagay sa isang hiwalay na module o component library.

Mga kalamangan at kahinaan ng Feature-Sliced Design

Mga kalamangan ng FSD ay nagiging nakikita sa malalaking proyekto na may 10+ developers. Bawat developer o team ay humahawak ng sarili nitong slice, hindi ginagalaw ang code ng iba. Ang mga conflict sa git ay nababawasan ng 40–60% (datos mula sa feature-sliced.design case studies). Ang mga bagong feature ay idinaragdag nang walang panganib na masira ang mga umiiral na, kung gumagamit lamang sila ng pampublikong API ng slices. Ang refactoring ng isang feature ay hindi nangangailangan ng pagbabago ng iba — sapat na ang muling pagsulat ng ui/model/api sa loob ng isang slice, habang pinapanatili ang pampublikong API.

Mga kahinaan ng FSD — labis na pagkakasama-sama para sa maliliit na proyekto. Kung ang application ay binubuo ng 3–5 screens, pitong layers at segmentation sa loob ng bawat slice ay lumilikha ng mas maraming organizational code kaysa sa application mismo. Mataas ang antas ng pagpasok: ang mga bagong developer ay gumugugol ng 2–4 na linggo upang matutunan ang metodolohiya. Ang FSD ay hindi rin gaanong katugma sa mabilis na prototyping — ang prototype ay nangangailangan ng madalas na cross-layer imports na ipinagbabawal sa FSD at nagpapabagal ng mga iteration.

Inirerekomenda na magsimula sa mas simpleng Feature-based na istraktura at lumipat sa FSD kapag ang bilang ng mga screen ay lumampas sa 20, at ang team — 5 developers.