Chương 8: Các Mẫu Kiến Trúc

Giới Thiệu: Mẫu Kiến Trúc (Architectural Patterns)

Các mẫu thiết kế chiến thuật (tactical patterns) được thảo luận từ đầu Phần II đến nay — bao gồm Transaction Script, Active Record, Domain Model, và Event-Sourced Domain Model — đã định nghĩa các cách thức khác nhau để mô hình hóa và triển khai logic nghiệp vụ.

Các Mẫu Kiến Trúc (Architectural Patterns) đưa ra các nguyên tắc tổ chức cấu trúc cho toàn bộ mã nguồn (codebase). Chúng quy định việc phân chia trách nhiệm giữa các thành phần phần mềm, định hình các ranh giới trừu tượng, và thiết lập các quy tắc chi phối sự tương tác cũng như chiều phụ thuộc giữa các khối cấu thành hệ thống.

Trong chương này, chúng ta sẽ khảo sát và so sánh 3 mẫu kiến trúc kinh điển, nắm rõ bản chất cơ học, sự tương thích của chúng với các mẫu logic nghiệp vụ, và cách áp dụng linh hoạt trong thực tế:

• Kiến trúc Phân tầng (Layered Architecture): Mô hình phân rã mã nguồn truyền thống theo các mối quan tâm công nghệ (technological concerns).
• Kiến trúc Cổng & Bộ điều hợp (Ports & Adapters / Hexagonal Architecture): Mô hình đặt logic nghiệp vụ làm trung tâm, đảo ngược hoàn toàn sự phụ thuộc với hạ tầng kỹ thuật.
• Phân tách Trách nhiệm Lệnh và Truy vấn (CQRS - Command-Query Responsibility Segregation): Mô hình cho phép đại diện dữ liệu hệ thống dưới nhiều góc nhìn lưu trữ khác nhau, tách rời luồng ghi (Command) và luồng đọc (Query).

Kiến Trúc Phân Tầng (Layered Architecture)

Kiến trúc Phân tầng (Layered Architecture) là một trong những mẫu kiến trúc phổ biến và lâu đời nhất trong ngành kỹ thuật phần mềm. Nó phân rã cơ sở mã thành các tầng nằm ngang (horizontal layers), trong đó mỗi tầng chịu trách nhiệm cho một nhóm mối quan tâm kỹ thuật cụ thể.

Ba Tầng Cốt Lõi Của Hệ Thống

Theo phân loại kinh điển của Eric Evans trong cuốn sách Domain-Driven Design (2003), kiến trúc phân tầng bao gồm 3 tầng nền tảng:

1. Tầng Trình Diễn (Presentation Layer)

Tầng này đóng vai trò giao diện tiếp xúc trực tiếp giữa chương trình và thế giới bên ngoài. Nó là nơi người dùng hoặc các hệ thống khác tương tác với ứng dụng. Trách nhiệm chính bao gồm:

• Giao diện đồ họa người dùng (Graphical User Interface - GUI: Web pages, Single Page Apps, Desktop Apps).
• Giao diện dòng lệnh (Command-Line Interface - CLI).
• Các điểm cuối lập trình (API: RESTful endpoints, GraphQL, gRPC).
• Lắng nghe và tiêu thụ thông điệp từ Message Broker (Message Consumer).

Về cốt lõi, tầng trình diễn nhận dữ liệu đầu vào từ người dùng hoặc hệ thống ngoài, chuyển đổi nó thành định dạng nội bộ, kích hoạt các thao tác tương ứng ở tầng dưới, và đóng gói kết quả phản hồi lại cho người gọi.

2. Tầng Logic Nghiệp Vụ (Business Logic Layer)

Như tên gọi của nó, tầng này chứa toàn bộ các phép tính toán, quy tắc nghiệp vụ, quy trình vận hành và kiểm tra tính hợp lệ dữ liệu. Đây chính là trái tim của phần mềm — nơi hiện thực hóa một trong 4 mẫu logic nghiệp vụ mà chúng ta đã học: Transaction Script, Active Record, Domain Model, hoặc Event-Sourced Domain Model.

3. Tầng Truy Cập Dữ Liệu (Data Access Layer - DAL)

Tầng này cung cấp khả năng lưu trữ bền vững (persistence) cho dữ liệu hệ thống. Nó chịu trách nhiệm giao tiếp với cơ sở dữ liệu quan hệ (RDBMS), cơ sở dữ liệu NoSQL, kho lưu trữ tài liệu, lưu trữ đám mây (AWS S3, Google Cloud Storage), hoặc hệ thống tập tin nội bộ.

Mối Quan Hệ Giữa Các Tầng: Chiều Phụ Thuộc Hướng Xuống

Trong mô hình phân tầng nguyên bản, sự phụ thuộc luôn chảy theo chiều từ trên xuống dưới (top-down dependency):

• Tầng Trình Diễn phụ thuộc vào Tầng Logic Nghiệp Vụ.
• Tầng Logic Nghiệp Vụ phụ thuộc vào Tầng Truy Cập Dữ Liệu.

Có hai biến thể về mức độ kiểm soát phụ thuộc:

• Phân tầng Nghiêm ngặt (Strict Layering): Một tầng chỉ được phép giao tiếp với tầng nằm ngay bên dưới nó. Tầng Trình Diễn không được phép gọi trực tiếp Tầng Truy Cập Dữ Liệu mà bắt buộc phải thông qua Tầng Logic Nghiệp Vụ.
• Phân tầng Nới lỏng (Relaxed / Open Layering): Một tầng có thể bỏ qua tầng trung gian để gọi trực tiếp các tầng thấp hơn (ví dụ: Tầng Trình Diễn gọi trực tiếp Tầng Truy Cập Dữ Liệu để đọc dữ liệu báo cáo dạng chỉ-đọc nhằm tối ưu hóa hiệu năng).

Biến Thể Mở Rộng: Tầng Dịch Vụ (Service Layer)

Trong thực tế, người ta thường bổ sung thêm một tầng thứ tư nằm giữa Tầng Trình Diễn và Tầng Logic Nghiệp Vụ: Tầng Dịch Vụ (Service Layer).

"Tầng dịch vụ định nghĩa ranh giới của một ứng dụng bằng một lớp các dịch vụ; nó thiết lập tập hợp các thao tác khả dụng và điều phối phản ứng của ứng dụng trong từng thao tác." — Martin Fowler, "Patterns of Enterprise Application Architecture"

Để thấy rõ sự cần thiết của Service Layer, hãy xem xét đoạn mã Controller trong một ứng dụng MVC khi chưa có Service Layer:

namespace MvcApplication.Controllers
{
    public class UserController : Controller
    {
        [AcceptVerbs(HttpVerbs.Post)]
        public ActionResult Create(ContactDetails contactDetails)
        {
            OperationResult result = null;
            try
            {
                _db.StartTransaction();
                var user = new User();
                user.SetContactDetails(contactDetails);
                user.Save();
                _db.Commit();
                result = OperationResult.Success;
            }
            catch (Exception ex)
            {
                _db.Rollback();
                result = OperationResult.Exception(ex);
            }
            return View(result);
        }
    }
}

Trong ví dụ trên, Controller ở Tầng Trình Diễn đang phải gánh vác việc mở Transaction CSDL, khởi tạo Active Record User, gọi lưu và Rollback khi có lỗi. Nếu ngày mai chúng ta muốn mở thêm một Web API hoặc một CLI Tool, đoạn logic điều phối giao dịch này sẽ bị sao chép nhân bản ở khắp nơi!

Bằng cách tái cấu trúc và trích xuất logic điều phối vào UserService (Service Layer), chúng ta đạt được sự đóng gói hoàn hảo:

namespace ServiceLayer
{
    public class UserService
    {
        public OperationResult Create(ContactDetails contactDetails)
        {
            OperationResult result = null;
            try
            {
                _db.StartTransaction();
                var user = new User();
                user.SetContactDetails(contactDetails);
                user.Save();
                _db.Commit();
                result = OperationResult.Success;
            }
            catch (Exception ex)
            {
                _db.Rollback();
                result = OperationResult.Exception(ex);
            }
            return result;
        }
    }
}

namespace MvcApplication.Controllers
{
    public class UserController : Controller
    {
        private UserService _userService;

        [AcceptVerbs(HttpVerbs.Post)]
        public ActionResult Create(ContactDetails contactDetails)
        {
            var result = _userService.Create(contactDetails);
            return View(result);
        }
    }
}

Phân Biệt: Layers (Tầng Logic) vs Tiers (Tầng Vật Lý)

Nhiều kỹ sư thường nhầm lẫn giữa khái niệm Layer và Tier (hệ thống N-Tier):

Khi Nào Nên Áp Dụng Kiến Trúc Phân Tầng?

Do chiều phụ thuộc hướng xuống (Business Logic Layer phụ thuộc trực tiếp vào Data Access Layer), kiến trúc phân tầng là một sự kết hợp hoàn hảo cho hệ thống triển khai bằng Transaction Script hoặc Active Record.

Kiến Trúc Cổng & Bộ Điều Hợp (Ports & Adapters)

Kiến trúc Cổng và Bộ điều hợp (Ports & Adapters) — còn được gọi rộng rãi là Kiến trúc Lục giác (Hexagonal Architecture) — giải quyết triệt để điểm yếu chí tử của kiến trúc phân tầng bằng cách áp dụng Nguyên lý Đảo ngược Phụ thuộc (Dependency Inversion Principle - DIP).

Tái Cấu Trúc Bằng Nguyên Lý Đảo Ngược Phụ Thuộc (DIP)

Hãy xem quá trình chuyển đổi kỳ diệu từ Kiến trúc Phân tầng sang Ports & Adapters qua 3 bước:

Bước 1: Hợp nhất các mối quan tâm kỹ thuật vào Tầng Hạ Tầng (Infrastructure Layer). Cả Tầng Trình Diễn (Web, API) và Tầng Truy Cập Dữ Liệu (SQL, Cache, File) thực chất đều chỉ là các chi tiết giao tiếp với thế giới công nghệ bên ngoài. Do đó, ta gom chúng lại thành một Tầng Hạ Tầng duy nhất (Hình 8-8).

Bước 2: Đảo ngược chiều phụ thuộc (Dependency Inversion). Nguyên lý DIP khẳng định: "Các module cấp cao (Logic Nghiệp vụ) không được phụ thuộc vào các module cấp thấp (Hạ tầng). Cả hai phải cùng phụ thuộc vào các trừu tượng (Abstractions)." Vì vậy, ta đảo ngược hoàn toàn mũi tên: Tầng Hạ Tầng phải phụ thuộc vào Tầng Logic Nghiệp Vụ (Hình 8-9).

Bước 3: Bổ sung Tầng Ứng Dụng (Application Layer). Thêm một lớp mặt tiền điều phối bên ngoài tầng nghiệp vụ, tạo nên cấu trúc 3 lớp đồng tâm hoàn chỉnh (Hình 8-10).

Cơ Chế Hoạt Động: Ports (Cổng) và Adapters (Bộ Điều Hợp)

Tại sao mô hình này lại mang tên Ports & Adapters? Hãy quan sát cấu trúc tương tác trong Hình 8-11:

• Port (Cổng): Là các Interface trừu tượng do Tầng Nghiệp Vụ (hoặc Tầng Ứng Dụng) định nghĩa. Port mô tả những nhu cầu giao tiếp mà lõi nghiệp vụ cần để hoàn thành công việc, nhưng hoàn toàn không chứa bất kỳ mã công nghệ cụ thể nào.
• Adapter (Bộ điều hợp): Là các lớp triển khai cụ thể (concrete classes) nằm ở Tầng Hạ Tầng, thực thi các Interface của Port để làm việc với các công nghệ thực tế (SQL Server, MongoDB, RabbitMQ, SendGrid, REST...).

// PORT: Nằm trong Tầng Nghiệp Vụ (hoàn toàn thuần khiết)
namespace App.BusinessLogicLayer
{
    public interface IMessaging
    {
        void Publish(Message payload);
        void Subscribe(Message type, Action callback);
    }
}

// ADAPTER: Nằm trong Tầng Hạ Tầng (triển khai AWS SQS cụ thể)
namespace App.Infrastructure.Adapters
{
    public class SQSBus : IMessaging
    {
        public void Publish(Message payload)
        {
            // Gọi Amazon SQS SDK thực tế
        }

        public void Subscribe(Message type, Action callback)
        {
            // Lắng nghe tin nhắn từ hàng đợi AWS SQS
        }
    }
}

Nhờ có kỹ thuật Dependency Injection (IoC Container), khi ứng dụng khởi chạy (bootstrapping), bộ điều hợp SQSBus sẽ được tự động tiêm vào cổng IMessaging mà logic nghiệp vụ không hề hay biết công nghệ bên dưới là gì!

Các Biến Thể Tương Đương: Hexagonal, Onion, và Clean Architecture

Trong văn bản và cộng đồng phát triển phần mềm, bạn sẽ thường xuyên nghe thấy các tên gọi khác nhau:

Tác giả Vlad Khononov lưu ý: Tất cả các mẫu trên đều dựa trên cùng một triết lý thiết kế duy nhất: đặt Logic Nghiệp Vụ ở trung tâm và đảo ngược sự phụ thuộc của hạ tầng! Sự khác biệt chỉ nằm ở hệ thống thuật ngữ.

Khi Nào Nên Áp Dụng Ports & Adapters?

Việc tách bạch hoàn toàn logic nghiệp vụ khỏi mọi chi tiết công nghệ khiến Ports & Adapters trở thành sự lựa chọn hoàn hảo nhất cho Domain Model và Event-Sourced Domain Model.

Command-Query Responsibility Segregation (CQRS)

Mẫu kiến trúc CQRS (Phân tách Trách nhiệm Lệnh và Truy vấn) được xây dựng trên cùng các nguyên tắc tổ chức của Ports & Adapters, nhưng bổ sung một đột phá mang tính cách mạng trong cách thức quản trị dữ liệu của hệ thống: nó cho phép biểu diễn dữ liệu của cùng một thực thể dưới nhiều mô hình lưu trữ lâu bền khác nhau.

Mô Hình Hóa Đa Ngôn Ngữ Dữ Liệu (Polyglot Modeling & Persistence)

Trong hầu hết các hệ thống thực tế, việc ép buộc một mô hình dữ liệu duy nhất phục vụ cho tất cả các nhu cầu là một điều bất khả thi:

• Xử lý giao dịch trực tuyến (OLTP): Cần dữ liệu chuẩn hóa cao độ (3rd Normal Form), khóa ngoại, ràng buộc chặt chẽ để thực thi giao dịch ACID và bảo vệ bất biến.
• Xử lý phân tích & Báo cáo (OLAP): Cần dữ liệu phi chuẩn hóa (denormalized), cấu trúc dạng cột (columnar) để tính toán tổng hợp cực nhanh.
• Tìm kiếm người dùng: Cần máy chủ chỉ mục văn bản (Elasticsearch / OpenSearch).

Mô Hình Lệnh (Command) vs Mô Hình Đọc (Read Models)

Đúng như tên gọi của nó, CQRS phân tách rạch ròi trách nhiệm của các mô hình thành 2 nhóm chuyên biệt (Hình 8-12):

Cơ Chế Chiếu Mô Hình Đọc: Đồng Bộ vs Bất Đồng Bộ

Làm thế nào để các thay đổi từ Mô hình Lệnh được truyền tải sang các Mô hình Đọc? Có hai cơ chế chính:

1. Phép Chiếu Đồng Bộ (Synchronous Projections)

Trong mô hình đồng bộ, việc cập nhật mô hình đọc diễn ra ngay tại thời điểm lệnh được xử lý hoặc thông qua cơ chế Catch-up Subscription:

Để triển khai Catch-up Subscription trên cơ sở dữ liệu quan hệ, bảng dữ liệu thường có một cột số tăng tự động (Checkpoint) để bộ đọc biết chính xác bản ghi nào mới được thêm vào (Hình 8-15):

• Ưu điểm: Tính nhất quán mạnh — người dùng gửi lệnh xong đọc lại thấy ngay kết quả mới.
• Nhược điểm: Làm giảm tốc độ ghi do phải cập nhật nhiều bảng/kho dữ liệu trong cùng luồng xử lý.

2. Phép Chiếu Bất Đồng Bộ (Asynchronous Projections)

Mô hình Lệnh xuất các Domain Event ra một Message Broker (Kafka, RabbitMQ, AWS EventBridge). Các tiến trình xử lý nền (Projection Engines) độc lập tiêu thụ sự kiện và cập nhật vào các kho lưu trữ tương ứng (Hình 8-16):

Hiểu Lầm Phổ Biến Về CQRS: "Command Không Được Trả Về Dữ Liệu"?

Một ngộ nhận tai hại thường gặp khi kỹ sư tiếp cận CQRS là: "Lệnh (Command) chỉ được sửa đổi dữ liệu và phải trả về void. Muốn hiển thị dữ liệu thì client bắt buộc phải gọi riêng một Query qua Read Model."

Tác giả khẳng định: Quan niệm đó hoàn toàn SAI LẦM và dẫn đến trải nghiệm người dùng tồi tệ!

Một Command luôn luôn nên thông báo cho người gọi biết nó thành công hay thất bại. Nếu thất bại, nguyên nhân cụ thể là gì? Có lỗi xác thực nào không? Hơn thế nữa, Command hoàn toàn có thể — và trong nhiều trường hợp RẤT NÊN — trả về dữ liệu vừa tạo hoặc cập nhật (ví dụ: mã ID bản ghi vừa sinh, trạng thái mới) để UI có thể hiển thị tức thì cho người dùng.

Khi Nào Nên Áp Dụng CQRS?

CQRS đặc biệt giá trị cho các ứng dụng cần biểu diễn cùng một dữ liệu trong nhiều kho lưu trữ chuyên biệt (Polyglot Persistence). Và đặc biệt, CQRS là mẫu thiết kế BẮT BUỘC phải có đối với các hệ thống xây dựng theo mô hình Event-Sourced Domain Model (vì Event Store chỉ cho phép nạp sự kiện theo từng ID của một thực thể, không thể nào thực hiện các câu truy vấn phức tạp nếu không chiếu ra các Read Models).

Phạm Vi & Lát Cắt Kiến Trúc (Architectural Slices)

Một sai lầm phổ biến khác trong quản trị kiến trúc là áp đặt duy nhất một mẫu kiến trúc cho toàn bộ một Bounded Context hoặc toàn bộ doanh nghiệp.

Hãy nhớ lại: một Bounded Context có thể bao bọc nhiều Subdomain khác nhau (Core, Supporting, Generic) như minh họa trong Hình 8-17:

Nếu ép buộc một kiến trúc phức tạp như CQRS và Ports & Adapters cho một Subdomain hỗ trợ dạng CRUD đơn giản, bạn đang tự tạo ra độ phức tạp ngẫu nhiên (Accidental Complexity). Ngược lại, nếu dùng kiến trúc phân tầng đơn giản cho Subdomain cốt lõi thì hệ thống sẽ nhanh chóng suy thoái thành một "Đống bùn lớn" (Big Ball of Mud).

Lát Cắt Kiến Trúc (Architectural Slices)

Giải pháp tối ưu là phân chia hệ thống theo chiều dọc (Vertical Slices) kết hợp với phân chia theo chiều ngang (Horizontal Layers), như minh họa trong Hình 8-18:

Trong cùng một Bounded Context:

• Phân khu Core Subdomain có thể được xây dựng bằng Ports & Adapters + Event-Sourced Domain Model + CQRS.
• Phân khu Supporting Subdomain có thể chỉ cần Layered Architecture + Active Record.
• Phân khu Generic Subdomain có thể dùng Transaction Script hoặc tích hợp phần mềm có sẵn của bên thứ ba.

Tổng Kết Chương

Chương này đã mang lại bức tranh toàn cảnh về cách tổ chức cơ sở mã để hỗ trợ các mẫu triển khai logic nghiệp vụ:

Trong chương tiếp theo — Chương 9: Các Mẫu Giao Tiếp (Communication Patterns) — chúng ta sẽ tìm hiểu cách kết nối và chuyển tải thông tin an toàn giữa các thành phần phân tán thông qua Outbox Pattern, Saga, và Process Manager!

Bài Tập Ôn Tập & Thảo Luận Nghiệp Vụ

Dưới đây là 5 câu hỏi ôn tập kèm lời giải chi tiết và trích dẫn chuẩn xác từ tác giả Vlad Khononov (Appendix B).