NodeJS Clean Architecture - Những nguyên tắc cơ bản và lợi ích

Các bài viết cùng chuyên mục

• Part 1: NodeJS Clean Architecture - Những nguyên tắc cơ bản và lợi ích: Bài viết này
• Part 2: NodeJS Clean Architecture - Business Domain và Technical Domain

Hãy tưởng tượng việc xây dựng một ngôi nhà mà không có kế hoạch nhất quán, nơi tường, mái và nền móng hòa quyện vào một sự hỗn loạn vui vẻ... Đúng vậy, đó chính là điều thế giới phát triển phần mềm có thể trông như thế nào! Đừng tự lừa dối bản thân; điều đó xảy ra (quá) thường xuyên. Chúng ta có lẽ đều đã từng đối mặt với một mớ spaghetti, một đoạn code mà mọi thứ đều trộn lẫn và khó bảo trì. Clean Architecture sẽ là người thợ xây dựng giúp đỡ việc xây dựng ngôi nhà, mang lại một khung công việc để kiểm soát sự phức tạp ngày càng tăng của project chúng ta.

Clean Architecture là gì?

Clean Architecture không chỉ là một từ thông dụng. Nó là kết quả từ công trình của Robert C. Martin (một bài báo xuất bản năm 2012 và sau đó là một cuốn sách xuất bản năm 2017), nó là một khái niệm ngày càng cần thiết trong phát triển phần mềm, mang lại một cách tiếp cận có cấu trúc để thiết kế các ứng dụng mạnh mẽ, dễ bảo trì và có khả năng mở rộng.

Trước tiên, hãy định nghĩa các khái niệm cơ bản.

Định nghĩa

Clean Architecture nhằm tách biệt rõ ràng các mối quan tâm, với các khía cạnh kinh doanh ở một bên và các khía cạnh kỹ thuật ở bên kia. Nó cũng nhằm duy trì sự kiểm soát cần thiết đối với các phụ thuộc, tránh bị ràng buộc chặt chẽ hoặc phụ thuộc vào chúng.

Đây là hai nguyên tắc cơ bản:

1. Tách biệt các mối quan tâm

Với Clean Architecture, hãy tưởng tượng mỗi thành phần của ứng dụng của bạn có một vai trò rõ ràng và riêng biệt. Business logic không trộn lẫn với các chi tiết kỹ thuật. Ứng dụng được chia thành Các Layers, mỗi Layers có trách nhiệm của mình.

2. Độc lập với các khung công việc và công cụ

Ở đây, sự linh hoạt là chìa khóa. Ứng dụng của bạn phải linh hoạt và có khả năng thích ứng với các thay đổi mà không làm ảnh hưởng đến sự ổn định của nó. Một lỗ hổng bảo mật nghiêm trọng trong một phụ thuộc? Yêu cầu GDPR đối với một phụ thuộc khác? Không sao, việc điều chỉnh mã, thay thế nó bằng một phụ thuộc khác, nên được thực hiện một cách dễ dàng.

Các Layers của Clean Architecture

Trong phần định nghĩa, chúng ta đã thảo luận về việc phân chia thành Các Layers riêng biệt, mỗi Layers có trách nhiệm và vai trò cụ thể, theo nguyên tắc cô lập. Hãy đi sâu vào chi tiết.

Lớp Thực thể (Entities)

Entities tạo thành trái tim. Chúng là các khối xây dựng của ứng dụng của bạn, những người bảo vệ Business logic, mà không cần lo lắng về các chi tiết kỹ thuật, lưu trữ dữ liệu, v.v.

Use Cases

Các Use Cases giống như những nhạc trưởng của ứng dụng của bạn. Chúng điều phối Business logic và đảm bảo rằng mọi thứ diễn ra suôn sẻ với sự phối hợp giữa các phần khác nhau của ứng dụng. Chúng mô tả rõ ràng các kịch bản Business logic. Tôi thích nhấn mạnh rằng góc nhìn của Product Owner có thể rất thú vị trong lớp này!

Layers Giao diện Người dùng

Trong Layers này, chúng ta xử lý các tương tác với thế giới bên ngoài. Giao diện người dùng xử lý các đầu vào và đầu ra, giống như một cổng kết nối giữa ứng dụng và các phụ thuộc bên ngoài.

Controller

Cuối cùng, lớp hạ tầng là nơi trú ngụ của công nghệ. Nó chịu trách nhiệm tương tác với các cơ sở dữ liệu, khung công việc và mọi thứ liên quan đến các khía cạnh kỹ thuật.

mỗi Layers đều được cô lập, độc lập. Để làm cho chúng giao tiếp với nhau, chúng ta sẽ sử dụng cái gọi là tiêm phụ thuộc.

Tại sao chọn Clean Architecture?

Bây giờ chúng ta đã thấy các nguyên tắc cơ bản và hiểu rõ các khái niệm cơ bản, hãy xem xét những lợi ích cụ thể của các nguyên tắc Clean Architecture.

Khả năng bảo trì và mở rộng tốt hơn

Người thợ xây dựng đã hoàn thành nhiệm vụ của mình, ngôi nhà được thiết kế tốt, và mỗi phòng đáp ứng một nhu cầu duy nhất. Nếu tôi muốn thêm một phòng hoặc thay đổi một cửa sổ, việc đó sẽ trở nên đơn giản hơn ngay lập tức! Clean Architecture mang lại sự linh hoạt này, cho phép ứng dụng thích nghi và phát triển mà không gặp khó khăn. Khác với code kiểu spaghetti, nơi việc kéo một bên có thể gây ra sự cố ở nơi khác.

Khả năng kiểm thử tốt hơn

Rất logic khi với nguyên tắc cô lập, tách biệt các mối quan tâm, nơi mỗi Layers có trách nhiệm của mình, cấu trúc code sẽ tạo điều kiện thuận lợi cho việc triển khai kiểm thử. Các thành phần đơn giản dẫn đến các kiểm thử đơn giản, kiểm thử đơn giản nghĩa là code mạnh mẽ hơn.

Độc lập kỹ thuật

Vẫn trong ngôi nhà của chúng ta, hãy nghĩ đến việc có thể thay đổi nội thất mà không ảnh hưởng đến cấu trúc cơ bản. Đây chính là một trong những nguyên tắc cơ bản của Clean Architecture, sự độc lập của lớp kỹ thuật. Nếu thay đổi bàn ăn yêu cầu thay đổi gạch, hai bức tường và ba cửa sổ, thì đó ngay lập tức là một dự án khác!

Hiểu rõ hơn về Code Base

Bằng cách tuân thủ các nguyên tắc tách biệt các mối quan tâm ở cấp độ cấu trúc của code, các nhà phát triển sẽ tìm thấy một con đường rõ ràng trong và giữa mỗi Layers, tạo điều kiện thuận lợi cho việc hiểu các phần khác nhau của ứng dụng.

Nhược điểm?

Tất nhiên, như thường lệ trong thế giới phát triển phần mềm, không có gì là hoàn toàn đen hoặc trắng. Nếu chúng ta nhận được lợi ích, thì chúng ta cũng nhận được nhược điểm: Phát triển phức tạp hơn, đường cong học tập dốc hơn một chút, có thể rất hữu ích khi tham gia vài khóa đào tạo. Chúng ta cũng có thể khiến kích thước mã nguồn lớn hơn, hoặc điều gì đó có thể được coi là phát triển quá mức, và sự phức tạp trong cấu hình ban đầu.

Kết luận

Clean Architecture không chỉ là một phương pháp phát triển; nó là một triết lý thay đổi cách chúng ta thiết kế các ứng dụng của mình. Bằng cách áp dụng các nguyên tắc của nó, chúng ta đảm bảo phát triển các ứng dụng mạnh mẽ, có khả năng mở rộng và dễ bảo trì hơn. Và chắc chắn, nó cũng là một sự cải thiện trong trải nghiệm của nhà phát triển, điều mà chúng ta sẽ đề cập trong một bài viết riêng.

Nhưng nó cũng không phải là một giải pháp kỳ diệu! Nó là một kiến trúc phát triển, giống như các kiến trúc khác, và giống như các kiến trúc khác sẽ xuất hiện trong tương lai. Bạn phải tự quyết định xem Clean Architecture có phải là lựa chọn tốt cho dự án của bạn, ngữ cảnh của bạn hay không. Trong một trong những trải nghiệm của tôi, chúng tôi đã phát triển một POC, với mục đích xác nhận một thị trường và các thông số kỹ thuật của Web 3. Chúng tôi đã tiến hành mà không có các thông số kỹ thuật chức năng thực sự; mỗi ngày mang đến, loại bỏ, thay đổi một tính năng: Sẽ quá tốn kém để đảm bảo có một cấu trúc mã sạch cho mã mà chúng tôi đã lên kế hoạch "vứt bỏ."

Nhưng dù sao đi nữa, với sự gia tăng của các AI hoặc các ứng dụng Low Code / No Code (và cả hai cùng một lúc trong tương lai?), thị phần của các ứng dụng được phát triển không bằng AI sẽ tiếp tục phát triển và chiếm lĩnh vị trí của nó, đó là niềm tin của tôi. Bất kỳ ứng dụng nào không rơi vào danh mục này sẽ phức tạp hơn, sẽ yêu cầu giải quyết các thách thức mà Low Code / No Code hoặc AI không thể giải quyết. Vì vậy, nó sẽ nhất thiết đòi hỏi một cấu trúc vững chắc, mạnh mẽ, có khả năng mở rộng và bảo trì, tất cả những gì mà Clean Architecture mang lại hôm nay, và có thể là một phương pháp mới hoặc các nguyên tắc mới vào ngày mai!

Bài viết này là phần giới thiệu về Clean Architecture và là một phần của loạt bài viết chuyên về chủ đề này. Hãy theo dõi để biết thêm!

Take care, Coder kiếm cơm