Feature-Sliced Design: Lời giải cho bài toán "Spaghetti Code" trong dự án Frontend phức tạp

Các lập trình viên Frontend thường đối mặt với một vấn đề kinh điển: khi ứng dụng mở rộng, các component trở nên chằng chịt, và một thay đổi nhỏ ở module này có thể làm hỏng logic ở module khác. Đây là bài toán về khả năng mở rộng (scaling). Để giải quyết, chúng ta cần một kiến trúc đảm bảo sự lỏng lẻo trong liên kết (loose coupling) và chặt chẽ trong nội tại (high cohesion).

Bài viết này sẽ phân tích sâu về Feature-Sliced Design (FSD), một phương pháp kiến trúc đang trở thành tiêu chuẩn cho các dự án lớn. Chúng ta sẽ đi qua hệ thống phân cấp, so sánh với các kiến trúc cổ điển và lý giải tại sao đây là lựa chọn tối ưu.

Cấu trúc phân cấp: Layers, Slices, và Segments

Để hiểu FSD, cần nắm rõ ba khái niệm phân rã cốt lõi: Layer (Tầng), Slice (Mảng nghiệp vụ), và Segment (Phân khúc kỹ thuật).

1. Layers (Cấp độ 1)

Layers là các thư mục cấp cao nhất và được chuẩn hóa. Quy tắc quan trọng nhất của FSD là dòng chảy dữ liệu đơn chiều: một layer chỉ được phép import các thành phần từ các layer nằm dưới nó.

Chi tiết trách nhiệm từng layer (từ trên xuống dưới):

• App: Điểm khởi tạo của ứng dụng. Nơi chứa logic setup, providers, global styles, và khai báo type toàn cục.
• Processes: (Deprecated/Tùy chọn) Xử lý các quy trình phức tạp trải dài trên nhiều trang (ví dụ: quy trình đăng ký nhiều bước). Trong FSD hiện đại, phần này thường được gộp vào Features hoặc Pages.
• Pages: Layer cấu trúc trang. Nó tập hợp các widgets, features và entities để tạo thành một giao diện hoàn chỉnh cho người dùng.
• Widgets: Các khối UI độc lập (ví dụ: Header, NewsFeed, Sidebar) được ghép từ entities và features.
• Features: Các kịch bản người dùng mang giá trị nghiệp vụ (ví dụ: "Thêm vào giỏ", "Like bài viết", "Đánh giá sản phẩm").
• Entities: Các thực thể nghiệp vụ (Business Entities) như User, Product, Comment. Layer này chứa logic hiển thị và dữ liệu, không chứa hành động trực tiếp của người dùng.
• Shared: Tầng đáy. Chứa code tái sử dụng không gắn với nghiệp vụ cụ thể (UI Kit, cấu hình Axios, helpers, utils).

  

Quy tắc tương tác: Features thường chứa tính tương tác (actions), trong khi Entities chứa dữ liệu. Features có thể dùng Entities, nhưng Entities tuyệt đối không được dùng Features.

2. Slices (Cấp độ 2)

Trong mỗi Layer, chúng ta có các Slices. Slice chia code theo lĩnh vực nghiệp vụ (business domain). Tên của Slice không cố định mà phụ thuộc vào dự án.

Ví dụ: Trong layer entities có thể có các slice user, product. Trong layer features có thể có auth-by-email, add-to-cart.

Quy tắc cốt lõi: Các Slice trong cùng một Layer không được phép import lẫn nhau. Điều này đảm bảo tính cô lập cao (High Cohesion).

3. Segments (Cấp độ 3)

Một Slice được cấu thành từ các Segments. Đây là các phân chia mang tính kỹ thuật:

• ui: Các component giao diện (React/Vue...).
• model: Quản lý state (Redux, Zustand) và logic nghiệp vụ.
• api: Các request server và DTO.
• lib: Các hàm tiện ích bổ trợ riêng cho slice đó.
• config: Các hằng số cấu hình.

Sức mạnh của Public API

Một trong những điểm kỹ thuật mạnh nhất của FSD là khái niệm Public API. Mỗi slice hoặc segment đều phải có một file index.ts hoặc index.js.

File này đóng vai trò như một cánh cổng. Nó chỉ export những gì bên ngoài được phép sử dụng. Các logic nội bộ (internal helpers) sẽ được đóng gói kín bên trong.

// features/auth-by-email/index.ts

// Chỉ export những thành phần này cho ứng dụng dùng
export { LoginForm } from './ui/LoginForm';
export { loginReducer } from './model/slice';

// Các hàm validation nội bộ trong ./lib/validation.ts
// KHÔNG được export, giữ cho namespace sạch sẽ.

Cơ chế này giúp việc refactoring trở nên an toàn. Bạn có thể thay đổi toàn bộ logic bên trong, miễn là Public API không đổi, phần còn lại của ứng dụng sẽ không bị ảnh hưởng.

Logic kiến trúc: Trừu tượng và Cô lập

FSD áp dụng các nguyên lý kỹ thuật phần mềm (OOP) như Đóng gói (Encapsulation) và Trừu tượng hóa (Abstraction) trực tiếp vào cấu trúc thư mục.

• Các layer dưới (Shared, Entities): Tính trừu tượng cao, tái sử dụng nhiều, ít thay đổi.
• Các layer trên (Pages, App): Gắn chặt với nghiệp vụ cụ thể, tính tái sử dụng thấp, hay thay đổi.

  

So sánh với các kiến trúc khác

FSD vs. Kiến trúc cổ điển (Classic)

Kiến trúc cổ điển thường nhóm file theo loại kỹ thuật (ví dụ: /components, /hooks, /services). Dù dễ bắt đầu, cấu trúc này thất bại ở các dự án lớn vì tạo ra các liên kết ngầm (implicit connections). Thư mục components trở thành "bãi rác" chứa logic hỗn độn.

FSD vs. Kiến trúc Module đơn giản

Kiến trúc module đơn giản nhóm theo tính năng nhưng thường thiếu quy tắc phụ thuộc nghiêm ngặt. Module A gọi Module B, Module B lại gọi ngược Module A, dẫn đến vòng lặp phụ thuộc (circular dependency) và khó tách code (code splitting).

Tổng kết ưu nhược điểm

Kết luận

Feature-Sliced Design không chỉ là cách đặt tên thư mục; nó là một hệ tư duy buộc lập trình viên phải suy nghĩ về giá trị và phạm vi của code. Mặc dù đòi hỏi sự đầu tư ban đầu về mặt kiến thức, nhưng lợi ích về khả năng bảo trì dài hạn cho các ứng dụng Enterprise là vô giá.