Trong kiến trúc SOA, việc phân rã các monolithic application thành nhiều Service độc lập thường dẫn đến tình trạng Distributed Monolith nếu thiết kế ranh giới nghiệp vụ không chuẩn xác. Làm thế nào để áp dụng chiến lược Domain-Driven Design (DDD) và nguyên lý Bounded Context để phân chia ranh giới dịch vụ hiệu quả?

Question

Accepted Answer

Bản chất vấn đề
Lỗi phổ biến của các lập trình viên khi mới tiếp cận SOA là chia nhỏ hệ thống dựa trên tầng kỹ thuật (UI Service, Business Service, Database Service) hoặc chia quá nhỏ theo từng bảng cơ sở dữ liệu. Kết quả là tạo ra một hệ thống Distributed Monolith: các dịch vụ phụ thuộc chéo lẫn nhau, gọi vòng lặp (Circular Dependency) và phải gọi database của nhau liên tục qua mạng.
Giải pháp: Domain-Driven Design (DDD) và Bounded Context
Để phân rã dịch vụ SOA chuẩn xác, cần dựa trên ranh giới nghiệp vụ (Business Domain) chứ không phải ranh giới công nghệ.

Ubiquitous Language (Ngôn ngữ thống nhất): Xác định các thuật ngữ nghiệp vụ rõ ràng giữa nhóm phát triển phần mềm và các chuyên gia nghiệp vụ (Domain Experts).
Bounded Context (Ngữ cảnh giới hạn): Là ranh giới rõ ràng bên trong đó một mô hình miền (Domain Model) được áp dụng nhất quán. Bên ngoài ranh giới này, các thuật ngữ có thể mang ý nghĩa hoàn toàn khác.
Ví dụ thực tế: Khái niệm Customer trong hệ thống Sales (Bán hàng) chứa thông tin địa chỉ giao hàng và lịch sử mua sắm. Tuy nhiên, khái niệm Customer trong hệ thống Billing (Thanh toán) chỉ cần thông tin mã số thuế và tài khoản ngân hàng. Trong SOA, đây phải là hai dịch vụ độc lập với hai mô hình dữ liệu riêng biệt.

Nguyên tắc giao tiếp giữa các Bounded Context

Shared Database là cấm kỵ: Tuyệt đối không cho phép hai dịch vụ độc lập cùng đọc/ghi trực tiếp vào một cơ sở dữ liệu vật lý.
Giao tiếp qua Anti-Corruption Layer (ACL): Khi dịch vụ này cần dữ liệu từ dịch vụ khác, nó phải thông qua API công khai hoặc Event Bus và dịch dữ liệu đó sang mô hình riêng của mình thông qua lớp ACL để tránh phụ thuộc cấu trúc bên trong của dịch vụ nguồn.

Kinh nghiệm thực chiến

Khi phỏng vấn ở cấp độ Middle, bạn cần nhấn mạnh vào việc phân tích biểu đồ Event Storming để tìm ra ranh giới Bounded Context.
Tránh thiết kế các dịch vụ quá nhỏ (Nano-services) vì chi phí quản lý vận hành (Operational Overhead) sẽ vượt trội hơn lợi ích mang lại. Ranh giới dịch vụ tối ưu thường tương ứng với một Aggregate Root lớn hoặc một nghiệp vụ hoàn chỉnh có thể tự chủ hoạt động.

Bản chất vấn đề

Làm Chủ Phỏng Vấn & Nâng Cao Trình Độ Chuyên Nghiệp

Tải Tuyển Tập 100+ Câu Hỏi Phỏng Vấn Chuyên Sâu (PDF)

Cần Mentor Phỏng Vấn Thử 1-1 & Tối Ưu CV?

Kiểm Tra CV Chuẩn ATS Miễn Phí

Câu hỏi soa liên quan cùng chủ đề