Giới thiệu Các nhà phát triển Frontend thường gặp phải vấn đề liên quan đến kiến trúc ứng dụng. Nó yêu cầu sử dụng một kiến trúc có thể dễ dàng mở rộng quy mô và cung cấp khả năng ghép nối lỏng lẻo cũng như tính gắn kết cao giữa các mô-đun ứng dụng. Bài viết này thảo luận về kiến trúc Thiết kế theo tính năng, theo ý kiến của tôi, đây là kiến trúc tốt nhất trong số các tùy chọn có sẵn. Nó cũng khám phá ý tưởng về FSD và các vấn đề mà phương pháp kiến trúc này giải quyết. Chúng ta sẽ so sánh FSD với các kiến trúc cổ điển và mô-đun cũng như xem xét ưu và nhược điểm của chúng. Đầu tiên và quan trọng nhất, hãy phân biệt ba khái niệm: lớp, lát và phân đoạn. Lớp Các lớp là các thư mục cấp cao nhất và là cấp độ phân rã ứng dụng đầu tiên. Chúng có số lượng hạn chế - tối đa 7 lớp - và được tiêu chuẩn hóa, mặc dù một số trong số đó là tùy chọn. Hiện nay, các lớp sau được phân biệt: Mỗi lớp có vùng trách nhiệm riêng và định hướng kinh doanh. Hãy xem xét từng lớp riêng biệt. app: Đây là nơi logic ứng dụng được khởi tạo. Nhà cung cấp, bộ định tuyến, kiểu toàn cầu, khai báo kiểu toàn cầu, v.v. được xác định ở đây. Nó phục vụ như là điểm vào cho ứng dụng. quy trình: Lớp này xử lý các quy trình trải rộng trên nhiều trang, chẳng hạn như đăng ký nhiều bước. Lớp này được coi là không được dùng nữa nhưng đôi khi vẫn có thể gặp phải. Đây là một lớp tùy chọn. trang: Lớp này bao gồm các trang của ứng dụng. widget: Đây là các thành phần UI độc lập được sử dụng trên các trang. tính năng: Lớp này xử lý các kịch bản và chức năng của người dùng mang giá trị kinh doanh. Ví dụ: lượt thích, viết đánh giá, xếp hạng sản phẩm, v.v. Đây là lớp tùy chọn. thực thể: Lớp này đại diện cho các thực thể kinh doanh. Các thực thể này có thể bao gồm người dùng, đánh giá, nhận xét, v.v. Đây là một lớp tùy chọn. được chia sẻ: Lớp này chứa các thành phần và tiện ích có thể tái sử dụng mà không bị ràng buộc với logic nghiệp vụ cụ thể. Nó bao gồm bộ giao diện người dùng, cấu hình Axios, cấu hình ứng dụng, các trình trợ giúp không bị ràng buộc bởi logic nghiệp vụ, v.v. Các lớp này giúp tổ chức cơ sở mã và thúc đẩy kiến trúc mô-đun, có thể bảo trì và mở rộng. Một trong những tính năng chính của Feature-Sliced Design là cấu trúc phân cấp của nó. Trong cấu trúc này, các thực thể không thể sử dụng chức năng từ các tính năng vì các tính năng này cao hơn trong hệ thống phân cấp. Tương tự, các tính năng không thể sử dụng các thành phần từ widget hoặc quy trình vì các lớp bên trên chỉ có thể sử dụng các lớp bên dưới. Điều này được thực hiện để duy trì dòng tuyến tính chỉ hướng theo một hướng. Lớp nào được đặt ở vị trí càng thấp trong hệ thống phân cấp thì càng có nhiều rủi ro khi thực hiện các thay đổi đối với nó vì nó có thể được sử dụng ở nhiều vị trí hơn trong mã. Ví dụ: bộ giao diện người dùng trong lớp chia sẻ được sử dụng trong các tính năng, tiện ích và thậm chí cả các lớp trang. Lát Trong mỗi lớp có các thư mục con - slice—mức phân rã ứng dụng thứ hai. Trong các phần, kết nối không phải là những thứ trừu tượng mà là các thực thể kinh doanh cụ thể. Mục tiêu chính của slice là nhóm mã theo giá trị của nó. Tên các lát cắt không được chuẩn hóa vì chúng được xác định trực tiếp bởi lĩnh vực kinh doanh của dự án. Ví dụ: trong thư viện ảnh, có thể có các phần như ảnh, album và thư viện. Mạng xã hội sẽ yêu cầu các phần như bài đăng, người dùng và nguồn cấp tin tức. Các đoạn có liên quan chặt chẽ có thể được nhóm lại theo cấu trúc trong một thư mục, nhưng chúng phải tuân thủ các quy tắc cách ly giống như các phần khác - không được có quyền truy cập chung vào mã trong thư mục này. Phân đoạn Mỗi lát bao gồm các phân đoạn. Các phân đoạn giúp phân chia mã trong một lát dựa trên mục đích của nó. Tùy thuộc vào thỏa thuận của nhóm, các phân đoạn có thể thay đổi về thành phần và cách đặt tên. Các phân đoạn sau đây được sử dụng phổ biến hơn: api - yêu cầu máy chủ cần thiết. UI - Các thành phần UI của slice. mô hình - Logic nghiệp vụ, tức là tương tác với trạng thái. Ví dụ: hành động và bộ chọn. lib - chức năng phụ trợ được sử dụng trong lát cắt. config - cấu hình cần thiết của slice, nhưng hiếm khi gặp phân đoạn config. const - hằng số cần thiết. API công khai Mỗi lát và phân đoạn có API công khai. API công khai được biểu thị bằng tệp index.js hoặc index.ts, cho phép chỉ trích xuất các chức năng cần thiết từ lát hoặc phân đoạn ra bên ngoài và tách biệt chức năng không cần thiết. Tệp chỉ mục đóng vai trò là điểm vào. Quy tắc dành cho API công khai: Các lát và phân đoạn ứng dụng chỉ sử dụng chức năng và thành phần của lát được xác định trong tệp chỉ mục API công khai. Phần bên trong của lát hoặc phân đoạn không được xác định trong API công khai được coi là tách biệt và chỉ mở để truy cập trong chính lát cắt hoặc phân đoạn đó. API công khai đơn giản hóa thao tác nhập và xuất, do đó, khi thực hiện thay đổi đối với ứng dụng, không cần phải thay đổi quá trình nhập ở mọi nơi trong mã. Đi sâu hơn vào kiến trúc Trừu tượng hóa và logic nghiệp vụ Lớp càng cao thì nó càng được gắn với nút nghiệp vụ cụ thể và càng chứa nhiều logic nghiệp vụ. Lớp càng thấp thì càng có nhiều tính trừu tượng, khả năng sử dụng lại và thiếu tính tự chủ trong lớp. FSD giải quyết vấn đề như thế nào? Một trong những nhiệm vụ của Thiết kế cắt lát tính năng là đạt được sự ghép nối lỏng lẻo và độ gắn kết cao. Điều quan trọng là phải hiểu FSD đạt được kết quả này như thế nào. Trong OOP, những vấn đề này từ lâu đã được giải quyết thông qua các khái niệm như , , và . Những khái niệm này đảm bảo sự tách biệt, khả năng sử dụng lại và tính linh hoạt của mã, trong đó thu được các kết quả khác nhau tùy thuộc vào cách sử dụng một thành phần hoặc chức năng. đa hình đóng gói kế thừa trừu tượng hóa Thiết kế cắt lát tính năng giúp áp dụng các nguyên tắc này trong giao diện người dùng. và đạt được thông qua các lớp. Vì các lớp thấp hơn là trừu tượng nên chúng có thể được sử dụng lại ở các lớp cao hơn và tùy thuộc vào điều kiện, một thành phần hoặc chức năng có thể hoạt động khác nhau dựa trên các tham số hoặc đạo cụ được chỉ định. Tính trừu tượng đa hình đạt được thông qua API công khai, giúp tách biệt những gì không cần thiết với bên ngoài theo từng lát và phân đoạn. Quyền truy cập vào các phân đoạn bên trong của một lát bị hạn chế và API công khai là cách duy nhất để truy cập chức năng và các thành phần từ một lát hoặc phân đoạn. Việc đóng gói cũng đạt được thông qua các lớp, vì các lớp cao hơn có thể tái sử dụng các lớp thấp hơn. Tính kế thừa So sánh với kiến trúc cổ điển Tôi tin rằng bạn đã nhiều lần bắt gặp kiến trúc cổ điển. Hầu hết các tác giả sử dụng nó trong các bài viết giáo dục và video YouTube do tính đơn giản của nó. Không có tiêu chuẩn cụ thể cho kiến trúc cổ điển. Tuy nhiên, bạn thường có thể thấy định dạng sau: Kiến trúc cổ điển có những nhược điểm đáng chú ý. Vấn đề lớn nhất là dự án trở nên khó bảo trì do các kết nối ngầm giữa các thành phần và sự lộn xộn của mô-đun. Những nhược điểm của kiến trúc cổ điển trở nên rõ ràng hơn theo thời gian. Dự án càng phát triển lâu thì kiến trúc ứng dụng càng trở thành một mớ hỗn độn khó giải quyết. Kiến trúc cổ điển phù hợp cho các dự án nhỏ không cần bảo trì liên tục hoặc các dự án thú cưng. Thiết kế theo tính năng, nhờ vào các khái niệm và tiêu chuẩn của nó, ngăn ngừa các vấn đề của kiến trúc cổ điển. Tuy nhiên, mức độ hiểu biết và kỹ năng của các nhà phát triển làm việc với FSD phải cao hơn khi làm việc với kiến trúc cổ điển. Thông thường, các nhà phát triển có dưới 2 năm kinh nghiệm chưa từng nghe nói đến FSD. Tuy nhiên, khi làm việc với Feature-Sliced Design, các vấn đề cần được giải quyết "ngay bây giờ" thay vì "sau này". Các vấn đề trong mã và những sai lệch so với các khái niệm trở nên rõ ràng ngay lập tức So sánh với kiến trúc mô-đun đơn giản Kiến trúc mô-đun đơn giản có một số nhược điểm: Đôi khi không rõ nên đặt chức năng vào đâu trong mô-đun hoặc thành phần. Khó khăn trong việc sử dụng các mô-đun trong một mô-đun khác. Các vấn đề với việc lưu trữ các thực thể kinh doanh. Sự phụ thuộc tiềm ẩn trong các hàm toàn cục, dẫn đến cấu trúc rối rắm. Có vẻ như trong bất kỳ dự án phức tạp hoặc phức tạp vừa phải nào, Thiết kế theo tính năng nên được ưu tiên hơn kiến trúc mô-đun đơn giản. FSD giải quyết được nhiều vấn đề kiến trúc cơ bản và có ít nhược điểm. Xét về tính đơn giản và tốc độ phát triển, kiến trúc mô-đun đơn giản có thể có lợi thế hơn FSD. Nếu cần MVP hoặc một dự án ngắn hạn đang được phát triển, kiến trúc mô-đun đơn giản có thể phù hợp hơn FSD. Nhưng trong mọi trường hợp khác, thiết kế theo từng tính năng sẽ phù hợp hơn. Tiềm năng của thiết kế theo tính năng FSD là một phương pháp kiến trúc trẻ. Tuy nhiên, nó đã được nhiều ngân hàng, fintech, B2B, thương mại điện tử và các công ty khác sử dụng. Đây là liên kết đến vấn đề GitHub với danh sách các công ty: . Vấn đề GitHub Kho lưu trữ GitHub với tài liệu chính thức của FSD đã có hơn 1,1 nghìn sao tại thời điểm xuất bản bài viết này. Tài liệu đang được tích cực mở rộng, đồng thời nhóm và cộng đồng phát triển FSD trên Telegram và Discord luôn sẵn sàng 24/7 để giúp đỡ mọi người với các câu hỏi liên quan đến kiến trúc. Tiềm năng của kiến trúc này được đánh giá cao và việc sử dụng nó được phổ biến rộng rãi trong các công ty lớn trên toàn thế giới. Với việc áp dụng phù hợp, FSD có tiềm năng trở thành giải pháp kiến trúc vượt trội trong lĩnh vực phát triển giao diện người dùng. Ưu điểm và nhược điểm của kiến trúc Thuận lợi Các thành phần kiến trúc có thể dễ dàng thay thế, thêm hoặc xóa Tiêu chuẩn hóa kiến trúc Khả năng mở rộng Phương pháp này độc lập với ngăn xếp phát triển. Kết nối được kiểm soát và rõ ràng giữa các mô-đun mà không có tác dụng phụ không mong muốn. Phương pháp kiến trúc định hướng kinh doanh. Nhược điểm Rào cản gia nhập cao hơn so với nhiều giải pháp kiến trúc khác. Yêu cầu nhận thức, văn hóa nhóm và tuân thủ các khái niệm. Những thách thức và vấn đề cần được giải quyết ngay lập tức, thay vì muộn hơn. Các vấn đề về mã và những sai lệch so với các khái niệm có thể được nhìn thấy ngay lập tức. Tuy nhiên, đây cũng có thể coi là một lợi thế. Phần kết luận Thiết kế cắt lát tính năng là một khám phá thú vị và có giá trị mà các nhà phát triển giao diện người dùng nên biết và có thể sử dụng. FSD có thể cung cấp cho các nhóm một nền văn hóa phát triển và kiến trúc linh hoạt, tiêu chuẩn hóa và có thể mở rộng. Tuy nhiên, việc sử dụng các khía cạnh tích cực của phương pháp này đòi hỏi kiến thức, nhận thức và kỷ luật trong nhóm. FSD nổi bật so với các kiến trúc khác nhờ định hướng kinh doanh rõ ràng, định nghĩa thực thể, thành phần chức năng và thành phần thành phần của ứng dụng. Bạn cũng có thể khám phá độc lập các ví dụ về cách sử dụng FSD trong các dự án và tài liệu Thiết kế cắt theo tính năng chính thức: Tài liệu chính thức Ví dụ. Máy khách GitHub Ví dụ. Cửa hàng giày thể thao và giày Nike Ví dụ. Sudoku Bài viết này có thể dài nhưng tôi hy vọng bạn đã học được điều gì đó mới mẻ. Tôi đánh giá cao rằng bạn đã đọc xong bài viết này. Nếu bạn có bất kỳ suy nghĩ hoặc câu hỏi nào, vui lòng để lại nhận xét! Cũng được xuất bản ở đây
