Chuyển đến nội dung chính

Các phương án thay thế

WIP

Bài viết đang trong quá trình hoàn thiện

Để đẩy nhanh việc phát hành bài viết, bạn có thể:


🍰 Stay tuned!

Lịch sử các cách tiếp cận kiến trúc

Big Ball of Mud​

WIP

Bài viết đang trong quá trình hoàn thiện

Để đẩy nhanh việc phát hành bài viết, bạn có thể:


🍰 Stay tuned!

Nó là gì; Tại sao nó phổ biến; Khi nào nó bắt đầu mang lại vấn đề; Phải làm gì và FSD giúp đỡ đây như thế nào

Smart & Dumb components​

WIP

Bài viết đang trong quá trình hoàn thiện

Để đẩy nhanh việc phát hành bài viết, bạn có thể:


🍰 Stay tuned!

Về cách tiếp cận; Về khả năng áp dụng trong frontend; Vị trí của methodology

Về sự lỗi thời, về quan điểm mới từ methodology

Tại sao cách tiếp cận component-container lại xấu?

Design Principles​

WIP

Bài viết đang trong quá trình hoàn thiện

Để đẩy nhanh việc phát hành bài viết, bạn có thể:


🍰 Stay tuned!

Chúng ta đang nói về điều gì; Vị trí của FSD

SOLID, GRASP, KISS, YAGNI, ... - và tại sao chúng không hoạt động tốt cùng nhau trong thực tế

Và nó tổng hợp các thực hành này như thế nào

DDD​

WIP

Bài viết đang trong quá trình hoàn thiện

Để đẩy nhanh việc phát hành bài viết, bạn có thể:


🍰 Stay tuned!

Về cách tiếp cận; Tại sao nó hoạt động kém trong thực tế

Sự khác biệt là gì, nó cải thiện khả năng áp dụng như thế nào, nó áp dụng các thực hành ở đâu

Clean Architecture​

WIP

Bài viết đang trong quá trình hoàn thiện

Để đẩy nhanh việc phát hành bài viết, bạn có thể:


🍰 Stay tuned!

Về cách tiếp cận; Về khả năng áp dụng trong frontend; Vị trí của FSD

Chúng giống nhau như thế nào (đối với nhiều người), chúng khác nhau như thế nào

Frameworks​

WIP

Bài viết đang trong quá trình hoàn thiện

Để đẩy nhanh việc phát hành bài viết, bạn có thể:


🍰 Stay tuned!

Về khả năng áp dụng trong frontend; Tại sao các framework không giải quyết vấn đề; tại sao không có cách tiếp cận duy nhất; vị trí của FSD

Không phụ thuộc vào framework, cách tiếp cận thông thường

Atomic Design​

Nó là gì?​

Trong Atomic Design, phạm vi trách nhiệm được chia thành các layer tiêu chuẩn.

Atomic Design được chia thành 5 layer (từ trên xuống dưới):

  1. pages - Chức năng tương tự với layer pages trong FSD.
  2. templates - Các component xác định cấu trúc của trang mà không gắn với nội dung cụ thể.
  3. organisms - Các module bao gồm các molecule và có logic kinh doanh.
  4. molecules - Các component phức tạp hơn nói chung không chứa logic kinh doanh.
  5. atoms - Các component UI không có logic kinh doanh.

Các module ở một layer chỉ tương tác với các module ở các layer bên dưới, tương tự như FSD. Tức là, các molecule được xây dựng từ các atom, các organism từ các molecule, các template từ các organism, và các page từ các template. Atomic Design cũng bao hàm việc sử dụng Public API trong các module để cô lập.

Khả năng áp dụng cho frontend​

Atomic Design tương đối phổ biến trong các dự án. Atomic Design phổ biến hơn trong các nhà thiết kế web hơn là trong phát triển. Các nhà thiết kế web thường sử dụng Atomic Design để tạo ra các thiết kế có thể mở rộng và dễ bảo trì. Trong phát triển, Atomic Design thường được trộn lẫn với các methodology kiến trúc khác.

Tuy nhiên, vì Atomic Design tập trung vào các component UI và sự kết hợp của chúng, một vấn đề phát sinh với việc triển khai logic kinh doanh trong kiến trúc.

Vấn đề là Atomic Design không cung cấp một mức trách nhiệm rõ ràng cho logic kinh doanh, dẫn đến việc phân tán nó qua các component và mức khác nhau, làm phức tạp hóa bảo trì và testing. Logic kinh doanh trở nên mờ nhạt, khiến việc phân tách rõ trách nhiệm trở nên khó khăn và làm code ít modular và có thể tái sử dụng hơn.

Nó liên quan đến FSD như thế nào?​

Trong bối cảnh của FSD, một số yếu tố của Atomic Design có thể được áp dụng để tạo ra các component UI linh hoạt và có thể mở rộng. Các layer atoms và molecules có thể được triển khai trong shared/ui trong FSD, đơn giản hóa việc tái sử dụng và bảo trì các yếu tố UI cơ bản.

├── shared
│   ├── ui
│   │   ├── atoms
│   │   ├── molecules
│   ...

So sánh FSD và Atomic Design cho thấy rằng cả hai methodology đều hướng tới tính modular và tái sử dụng nhưng tập trung vào các khía cạnh khác nhau. Atomic Design hướng tới các component trực quan và sự kết hợp của chúng. FSD tập trung vào việc chia chức năng của ứng dụng thành các module độc lập và các kết nối giữa chúng.

Feature Driven​

WIP

Bài viết đang trong quá trình hoàn thiện

Để đẩy nhanh việc phát hành bài viết, bạn có thể:


🍰 Stay tuned!

Về cách tiếp cận; Về khả năng áp dụng trong frontend; Vị trí của FSD

Về tính tương thích, phát triển lịch sử và so sánh