Architecture Pattern - Phần 2: Kiến trúc phân lớp (Layered architecture)

Xin chào các bạn, đây là Series Architecture Pattern!

Ở các bài trước Architecture Pattern - Phần 1, chúng ta đã tìm hiểu khái niệm và các đặc tính của kiến trúc phần mềm (software architecture) cũng như cách phân loại chúng.

Trong bài này, chúng ta sẽ cùng tìm hiểu một trong số mẫu kiến trúc phần mềm (architecture pattern) phổ biến tới mức trở thành kiến trúc "quốc dân". Đó là kiến trúc phân lớp (Layered architecture).

1. Kiến trúc phân lớp là gì?

Kiến trúc phân lớp (Layered architecture - còn được gọi là N-tier architecture) là kiến trúc phổ biến từ những năm 90 cho tới ngày nay. Mỗi lớp trong kiến trúc này có chức năng riêng và tương tác với lớp ngay trên hoặc dưới nó. Các mô hình sử dụng kiến trúc này bao gồm MVC, MVVM, ...

2. Thành phần của kiến trúc phân lớp

Các thành phần (component) trong kiến trúc phân lớp được tổ chức thành các lớp logic ngang, mỗi lớp thực hiện một vai trò cụ thể trong ứng dụng (ví dụ: logic trình bày - User interface hoặc logic nghiệp vụ - Business).

Mặc dù không có con số cụ thể về số lượng và loại lớp phải có, kiến trúc phân lớp thường bao gồm bốn lớp tiêu chuẩn: presentation, business, persistence, và database.

1. Lớp Presentation: Gồm các thành phần như giao diện người dùng, trình duyệt, ứng dụng di động, hoặc các thành phần tương tác với người dùng khác. Có chức năng hiển thị thông tin và kết quả từ lớp Logic cho người dùng và chuyển dữ liệu người dùng nhập vào lớp Logic.
2. Lớp Business: Đôi khi còn được gọi là lớp Service. Có nhiệm vụ xử lý các logic nghiệp vụ, nhận yêu cầu từ lớp Presentation, xử lý nó và gửi yêu cầu tương ứng đến lớp Persistence.
3. Lớp Persistence: Đảm nhiệm việc gửi  các yêu cầu đến lớp Database để thực hiện các thao tác liên quan đến dữ liệu.
4. Lớp Database: Bao gồm cơ sở dữ liệu và các thành phần liên quan như hệ quản trị cơ sở dữ liệu. Có nhiệm vụ quản lý cơ sở dữ liệu, thực hiện thao tác đọc và ghi dữ liệu và triển khai các truy vấn và lưu trữ dữ liệu theo cách được định nghĩa từ lớp Persistence.

Trong kiến trúc phân lớp, các lớp có thể ở trạng thái mở hoặc đóng. Hình minh hoạ ở dưới thể hiện kiến trúc phân lớp đóng. Các lớp cô lập (layers of isolation) được tạo ra nhằm đảm bảo sự độc lập giữa các lớp với nhau, thay đổi của lớp này không ảnh hưởng tới lớp khác.

Để làm rõ luận điểm này, chúng ta hãy cùng nhìn vào mô hình API được thiết kế theo kiến trúc quốc dân được sử dụng phổ biến sau:

Chúng ta có bốn lớp với các nhiệm vụ cụ thể:

1. Controller (Presentation Layer): Parse các request từ client
2. Service (Business Layer): Xử lý logic nghiệp vụ
3. Repository (Persistence Layer): Mapping dữ liệu từ service với database (DAO - Data access object hoặc DTO - Data transfer object)
4. Database (Database Layer): Cập nhật dữ liệu trong database

Dù có ưu điểm tách biệt logic giữa các tầng, kiến trúc phân lớp vẫn có một yếu điểm dễ thấy là logic phải được truyền theo thức tự các tầng, bất kể tầng đó có xử lý dữ liệu hay không. Điều này gây ra sự lãng phí tài nguyên.

3. Trường hợp nên dùng kiến trúc phân lớp

Nếu dự án có những hạn chế nhất định về thời gian và ngân sách, kiến trúc phân lớp là một sự lựa chọn thích hợp vì các lý do chính sau:

• Kiến trúc phân lớp thuộc loại kiến trúc monolithic nên nó không mang sự phức tạp như kiến trúc phân tán.
• Dựa trên mức độ phổ biến của kiến trúc phân lớp, hầu hết các nhà phát triển điều quen thuộc với nó, kiến việc vận hành, phát triển dự án trở nên dễ dàng hơn.
• Kiến trúc phân lớp thuộc nhóm kiến trúc phân vùng kỹ thuật nên việc sử dụng kiến trúc này phù hợp với nhiều tổ chức khác nhau do các nhóm được chia thành nhóm chuyên trách kỹ thuật như nhóm FE, nhóm BE, nhóm database, ...

4. Trường hợp không nên dùng kiến trúc phân lớp

• Nếu dự án của bạn đòi hỏi khả năng mở rộng, độ đàn hồi, khả năng chịu lỗi và hiệu năng thì kiến trúc phân lớp không phải là sự lựa chọn phù hợp. Nguyên nhân chủ yếu do bản chất của loại kiến trúc monolithic là khó mở rộng và khả năng chịu lỗi thấp. Một component trong hệ thống bị lỗi có thể dẫn tới lỗi cả ứng dụng.
• Nếu dự án của bạn có nhiều sự thay đổi về domain. Ví dụ, ứng dụng thương mại điện tử cần thêm tính năng livestream. Để hoàn thành yêu cầu này, bạn cần sửa nhiều lớp khác nhau như sửa schema của database (lớp database) gồm thêm bảng mới hoặc cột mới hoặc cả hai, sửa SQL trong lớp persistence, sửa logic của lớp business và sửa cả lớp presentation (giả sử cần thêm API mới). Việc thay đổi này có thể kém linh hoạt và mất nhiều thời gian vì scope phải sửa nhiều.
• Nếu team của bạn tổ chức thành các nhóm đa chức năng xử lý chung domain, nghĩa là trong cùng một team sẽ có nhiều thành viên có chuyên môn trên nhiều mảng khác nhau như FE, BE, designer, DA, ... thì việc này không hề phù hợp với bản chất của kiến trúc phân lớp (do thuộc phân vùng kỹ thuật).

5. Tổng kết

Kiến trúc phân lớp (Layered archtecture) chia hệ thống ra thành các lớp thực hiện chức năng riêng biệt. Mỗi lớp sẽ tương tác với lớp ở trên hoặc ở dưới nó.

Ưu điểm của kiến trúc phân lớp là các layer độc lập, đảm bảo logic không bị chồng chéo lẫn nhau. Tuy nhiên, vì phải đi theo thứ tự từng lớp một nên có thể dẫn tới hiệu năng không tốt do dữ liệu bị truyền qua những lớp không cần thiết.

Kiến trúc phân lớp sẽ phù hợp với những hệ thống đơn giản chưa cần nhiều khả năng mở rộng, khả năng chịu lỗi và hiệu năng. Ngoài ra, những dự án bị giới hạn bởi thời gian và ngân sách sẽ phù hợp với kiến trúc đơn giản này.

Hy vọng, qua loạt bài viết này, bạn đã có thêm những kiến thức hữu ích để áp dụng vào dự án của mình, và không ngừng nâng cao kỹ năng lập trình để tạo ra những sản phẩm phần mềm chất lượng và hiệu quả.

6. Tài liệu tham khảo

1. Fundamentals of Software Architecture - Mark Richards
2. Software Architecture Patterns - Mark Richards
3. Software Architecture Monday - Mark Richards
4. Microservices - Martin Flower