DDD: Phần 3 – Quản lý Domain Complexity: Khám phá Sức mạnh của Bounded Context trong Thiết kế phần mềm

Xem lại phần 2: https://minhphien.com/ddd-part-2-giao-tiep-va-ngon-ngu-chung-trong-domain-driven-design/

Trong hai phần trước, chúng ta đã hiểu rõ tầm quan trọng của ngôn ngữ chung (ubiquitous language) đối với việc giao tiếp giữa nhóm kỹ thuật và các domain expert trong môi trường phát triển phần mềm. Tuy nhiên, thực tế tại nhiều tổ chức, ngôn ngữ chung thường không đồng nhất do sự khác biệt trong nhận thức và mô hình tâm trí của các domain expert.

Chúng ta sẽ đào sâu vào khái niệm Bounded Context – một pattern của Domain-Driven Design (DDD) giúp chia nhỏ bối cảnh áp dụng ngôn ngữ chung một cách rõ ràng và hiệu quả.

Đặt vấn đề: Khi các mô hình miền không trùng khớp

Lấy ví dụ: trong một công ty telemarketing, bộ phận marketing định nghĩa “lead” là một notification khi người dùng để lại thông tin. Trong khi đó, bộ phận sales xem “lead” là toàn bộ quy trình tiếp cận, theo dõi, và chăm sóc khách hàng.

Sự khác biệt này có thể được lượt qua khi giao tiếp trực tiếp, nhưng đối với mã nguồn và hệ thống phần mềm, nó sẽ dẫn đến một trong hai trường hợp: over-engineering hoặc under-engineering.

Giải pháp: Bounded Context – Tạo ra những khu vực ranh giới rõ ràng

Bounded Context cho phép bạn chia nhỏ ngôn ngữ chung ra thành nhiều ngôn ngữ nhỏ, ứng với từng khu vực áp dụng. Như vậy, “lead” trong bối cảnh marketing và “lead” trong bối cảnh sales được định nghĩa và xây dựng mô hình khác nhau.

Bounded Context là gì?

• Nó là ranh giới giữa ngôn ngữ và mô hình: Bạn xây dựng một mô hình phù hợp cho từng vùng vấn đề
• Nó định nghĩa phạm vi: Trong mỗi bounded context, mô hình và quy tắc kinh doanh được đảm bảo đồng bộ
• Nó tiết kiệm tài nguyên tổ chức: Cho phép các nhóm phát triển vận hành độc lập mà không gây xung đột

Subdomain vs. Bounded Context

• Subdomain là khái niệm được khám phá từ chiến lược kinh doanh
• Bounded Context là khái niệm được thiết kế từ góc nhìn của kỹ sư phần mềm

Việc đồng nhất giữa subdomain và bounded context có thể rất hữu ích trong nhiều trường hợp. Tuy nhiên, việc linh hoạt thiết kế nhiều bounded context cho một subdomain là cách tốt để giải quyết nhiều vấn đề khác nhau.

Ranh giới của Bounded Context: Vật lý và Quyền sở hữu

• Vật lý: Mỗi bounded context nên là một service/subsystem riêng biệt, có vòng đời phát triển và deploy độc lập
• Quyền sở hữu: Mỗi bounded context nên được sở hữu bởi một nhóm duy nhất, tránh xung đột trong quy trình phát triển

Phân chia theo quyền sở hữu (Ownership Boundaries)

Nghiên cứu đã chỉ ra rằng: “Hàng rào tốt tạo nên hàng xóm tốt”. Trong các dự án phần mềm, ta có thể tận dụng ranh giới của mô hình—các Bounded Context—để đảm bảo các nhóm cùng tồn tại và làm việc hòa hợp. Việc phân chia công việc giữa các nhóm cũng là một quyết định chiến lược và có thể được đưa ra dựa trên mô hình Bounded Context.

🔸 Mỗi Bounded Context nên được một nhóm duy nhất xây dựng, phát triển và duy trì.
Không có hai nhóm nào được làm việc trên cùng một Bounded Context. Việc này loại bỏ những giả định ngầm mà các nhóm có thể hình thành về mô hình của nhau. Thay vào đó, họ buộc phải định nghĩa rõ ràng các giao thức giao tiếp để tích hợp mô hình và hệ thống của mình.

🔸 Lưu ý rằng mối quan hệ giữa nhóm và Bounded Context là một chiều:

• Một Bounded Context chỉ được sở hữu bởi một nhóm.
• Nhưng một nhóm có thể sở hữu nhiều Bounded Context, như minh họa trong Hình 3-8.

📊 Ví dụ: Nhóm 1 làm việc với các Bounded Context Marketing và Tối ưu hóa, trong khi Nhóm 2 đảm nhận Bounded Context Bán hàng.

Bounded Context trong thực tế

Trong một buổi đào tạo về Domain-Driven Design, một học viên từng hỏi:

“Thầy nói DDD giúp gắn kết thiết kế phần mềm với miền nghiệp vụ. Nhưng trong thực tế thì Bounded Context ở đâu? Doanh nghiệp đâu có khái niệm này?”

Thật vậy, các Bounded Context không hiển nhiên như các business domain hoặc subdomain, nhưng chúng luôn tồn tại, giống như mô hình tâm trí (mental model) của các domain expert. Chúng ta chỉ cần nhạy bén hơn để nhận ra cách chuyên gia suy nghĩ và nói về các thực thể và quy trình trong doanh nghiệp.

Ngữ nghĩa học & các miền ngữ nghĩa

DDD vay mượn khái niệm Bounded Context từ ngành từ vựng học:

• Miền ngữ nghĩa là vùng ý nghĩa mà trong đó các từ mang một hàm nghĩa cụ thể.
• Ví dụ: “monitor”, “port” hay “processor” mang ý nghĩa khác nhau trong miền phần mềm và phần cứng.

🍅 Ví dụ về từ “tomato” (cà chua):

• Trong thực vật học: cà chua là trái cây (vì nó phát triển từ hoa và chứa hạt).
• Trong ẩm thực: là rau (do hương vị và cách chế biến).
• Trong thuế quan Hoa Kỳ (năm 1893): để áp thuế nhập khẩu, cà chua bị phân loại là rau.

➡️ Kết luận: cà chua là trái cây trong miền thực vật học, rau trong ẩm thực, và hàng chịu thuế trong miền luật thuế.

Khoa học và các mô hình mâu thuẫn nhưng hữu ích

• Newton và Einstein có hai mô hình mô tả trọng lực khác nhau.
• Newton: thời gian và không gian là tuyệt đối.
• Einstein: thời gian và không gian là tương đối với người quan sát.

Mặc dù khác nhau, cả hai mô hình đều có ích trong Bounded Context cụ thể.

Ví dụ thực tế: Mua tủ lạnh

Bạn nhìn thấy một tấm bìa cứng. Nó không giống một chiếc tủ lạnh, nhưng nó là mô hình của tủ lạnh Siemens KG86NAI31L.

• Mục tiêu: kiểm tra xem tủ lạnh có chui lọt qua cửa bếp hay không.
• Chỉ cần bìa cứng đúng kích thước chiều rộng và sâu. Kiểm tra chiều cao bằng thước dây.

✅ Không cần mô hình 3D. Một mô hình đơn giản đã đủ phù hợp với mục tiêu.
Điều này phản ánh nguyên lý “Tất cả các mô hình đều sai, nhưng một số mô hình thì hữu ích.”

Tổng kết

• Khi gặp mâu thuẫn trong mô hình tâm trí của các chuyên gia, hãy phân tách Ubiquitous Language thành các Bounded Context riêng biệt.
• Một Bounded Context là nơi mà một mô hình và ngôn ngữ chung hoạt động một cách nhất quán.
• Subdomain là thứ được phát hiện (discovered) từ phân tích doanh nghiệp.
• Bounded Context là thứ được thiết kế (designed) trong quá trình xây dựng hệ thống.
• Một nhóm nên sở hữu và duy trì một hoặc nhiều Bounded Context, không chia sẻ một Context giữa các nhóm.