Feature-Sliced Design: bản chất và phương pháp phân chia theo tính năng

Feature-Sliced Design là gì?

Feature-Sliced Design (FSD) là một phương pháp kiến trúc ứng dụng frontend lần đầu tiên được đề xuất vào năm 2021 bởi cộng đồng feature-sliced.design. Ý tưởng cốt lõi của FSD là nhóm mã theo tính năng kinh doanh (slice), mỗi slice là một đơn vị tự cung cấp: chứa logic kinh doanh riêng, giao diện người dùng, tương tác API, mô hình dữ liệu và kiểm thử. Điều này phân biệt FSD với kiến trúc lớp cổ điển nơi mã được chia theo tiêu chí kỹ thuật (controller, service, repository).

Phương pháp này vay mượn các khái niệm từ Domain-Driven Design (DDD) và Bounded Context: mỗi tính năng của ứng dụng là một bounded context riêng biệt với ranh giới rõ ràng. Các thay đổi bên trong một tính năng không được làm hỏng các tính năng khác nếu chúng chỉ sử dụng API công khai của slice. Theo khảo sát State of Frontend 2024, FSD đứng thứ hai về mức độ phổ biến trong số các kiến trúc React (23%), chỉ sau cấu trúc Feature-based không chính thức (31%).

Trong phát triển di động, FSD thích ứng với đặc thù của mô-đun Android và framework iOS. Tại IT Sectr, chúng tôi sử dụng FSD cho các dự án có 10+ màn hình và 3+ nhóm — phương pháp này cho phép phát triển tính năng độc lập và giảm xung đột git xuống 40% so với kho lưu trữ đơn không có ranh giới slice.

Bảy lớp của FSD: cấu trúc và quy tắc import

FSD định nghĩa bảy lớp phân cấp, mỗi lớp chứa mã ở một mức trừu tượng nhất định. Quy tắc kiến trúc chính là các lớp chỉ có thể import mã từ các lớp bên dưới. Vi phạm quy tắc này (import lớp features vào entities) được coi là lỗi kiến trúc và bị chặn bởi linter.

Ví dụ cấu trúc thư mục của dự án FSD:

src/
├── app/                    // Lớp ứng dụng
│   ├── providers/
│   ├── router/
│   └── styles/
├── pages/                   // Trang — tổ hợp tính năng
│   └── main/
├── features/                // Tính năng — kịch bản người dùng
│   ├── auth/                // Slice «Xác thực»
│   │   ├── ui/
│   │   ├── model/
│   │   └── api/
│   └── productList/         // Slice «Danh sách sản phẩm»
│       ├── ui/
│       └── model/
├── entities/                // Thực thể kinh doanh
│   ├── user/
│   └── product/
├── widgets/                 // Thành phần tổng hợp
│   └── header/
└── shared/                  // Tiện ích dùng chung và UI-kit
    └── ui/

Quy tắc «các lớp chỉ nhìn xuống dưới» là nền tảng của FSD. Nếu feature auth import entity user — điều đó đúng. Nếu entity user bắt đầu import feature auth — đó là phụ thuộc vòng tròn và vi phạm cô lập. Để đảm bảo quy tắc này, các plugin ESLint (eslint-plugin-fsd) hoặc linter tùy chỉnh của API công khai slice được sử dụng.

Slice: ranh giới miền kinh doanh

Slice — đơn vị nhóm chính trong FSD, tương ứng với một tính năng hoặc thực thể kinh doanh. Mỗi slice nằm trong một trong bảy lớp (features, entities, widgets, pages) và chứa bộ mã hoàn chỉnh để triển khai chức năng cụ thể: thành phần UI, mô hình dữ liệu, client API, hằng số và kiểm thử.

Ranh giới slice được xác định bởi miền kinh doanh: feature auth bao gồm mọi thứ liên quan đến xác thực (biểu mẫu đăng nhập, biểu mẫu đăng ký, đặt lại mật khẩu); entity user bao gồm mô hình User, UserRepository và tuần tự hóa. Ranh giới không được chồng chéo: nếu feature auth cần dữ liệu người dùng — nó import entity user thay vì sao chép logic. Trong phát triển di động, slice FSD thường tương ứng với mô-đun Gradle trong Android hoặc gói Swift trong iOS.

Các slice bị cô lập nghiêm ngặt: cấu trúc bên trong của một slice không thể nhìn thấy được đối với các slice khác. Để tương tác giữa các slice, API công khai được sử dụng — tệp index.ts/index.js chỉ xuất những gì được phép sử dụng bên ngoài. Mọi thứ khác là mô-đun riêng tư. Cách tiếp cận này ngăn chặn các phụ thuộc ngẫu nhiên và đơn giản hóa việc tái cấu trúc: thay đổi triển khai riêng tư của một slice không ảnh hưởng đến các slice khác.

Phân đoạn: UI, API, Model, Lib bên trong slice

Bên trong mỗi slice FSD, mã được tổ chức thêm theo phân đoạn — các danh mục kỹ thuật lặp lại trong tất cả các slice. Bộ phân đoạn tiêu chuẩn bao gồm ui (thành phần giao diện), model (logic kinh doanh, Store, Actions, Reducer), api (yêu cầu máy chủ, biến đổi), lib (tiện ích và trình trợ giúp) và config (cấu hình tính năng).

Phân đoạn là khuyến nghị, không phải quy tắc nghiêm ngặt. Nếu slice nhỏ, các phân đoạn có thể được hợp nhất. Đối với slice lớn (tính năng có 10+ tệp), phân đoạn là bắt buộc — nếu không có nó, cấu trúc bên trong nhanh chóng biến thành «rổ» gồm 50 tệp, nơi việc tìm thành phần cần thiết mất nhiều phút. Trong phát triển di động, các phân đoạn thường được thay thế bằng cấu trúc tệp theo loại: mỗi tính năng là một tệp Swift riêng biệt hoặc lớp Kotlin với các kiểu bên trong.

FSD trong phát triển di động: thích ứng với Android và iOS

Trong phát triển di động, FSD thích ứng với các đặc điểm nền tảng — cấu trúc mô-đun của Android (mô-đun Gradle) và Swift Package Manager. Thích ứng Android giả định rằng mỗi slice là một mô-đun Gradle riêng biệt với build.gradle riêng. Các mô-đun feature-auth, feature-profile, entity-user, shared-ui được cô lập với nhau ở cấp độ xây dựng: feature-auth không thể import feature-profile trừ khi được chỉ định trong dependencies.

Thích ứng iOS được xây dựng trên Swift Package Manager: mỗi slice là một gói Swift với API công khai. Trong các dự án TCA, slice feature.auth chứa Reducer, Store, View và client API riêng. Theo Swift Community Survey 2024, 28% dự án iOS với TCA sử dụng kiến trúc slice gần với FSD.

Vấn đề chính của việc thích ứng FSD trên di động là sự trùng lặp của lớp shared. Trong phát triển di động, các thành phần UI (shared/ui) thường phụ thuộc vào nền tảng (Android Views vs Jetpack Compose vs SwiftUI), đòi hỏi các mô-đun shared riêng biệt cho mỗi công nghệ. Trong FSD, lớp shared thường độc lập với nền tảng (tiện ích, cấu hình), trong khi UI-kit được chuyển sang mô-đun riêng biệt hoặc thư viện thành phần.

Ưu và nhược điểm của Feature-Sliced Design

Ưu điểm của FSD trở nên rõ rệt trong các dự án lớn với 10+ nhà phát triển. Mỗi nhà phát triển hoặc nhóm làm việc trên slice riêng của mình mà không chạm vào mã của người khác. Xung đột git giảm 40–60% (dữ liệu từ nghiên cứu điển hình của feature-sliced.design). Các tính năng mới được thêm vào mà không có rủi ro làm hỏng tính năng hiện có, miễn là chúng chỉ sử dụng API công khai của slice. Tái cấu trúc một tính năng không yêu cầu thay đổi ở các tính năng khác — chỉ cần viết lại ui/model/api bên trong một slice trong khi giữ nguyên API công khai.

Nhược điểm của FSD — lồng ghép quá mức cho dự án nhỏ. Nếu ứng dụng gồm 3–5 màn hình, bảy lớp và phân đoạn bên trong mỗi slice tạo ra nhiều mã tổ chức hơn chính ứng dụng. Rào cản gia nhập cao: nhà phát triển mới mất 2–4 tuần để học phương pháp. Ngoài ra, FSD tương thích kém với tạo mẫu nhanh — tạo mẫu yêu cầu import xuyên lớp thường xuyên, bị cấm trong FSD và làm chậm các vòng lặp.

Khuyến nghị bắt đầu với cấu trúc Feature-based đơn giản hơn và chuyển sang FSD khi số lượng màn hình vượt quá 20 và nhóm vượt quá 5 nhà phát triển.