Trong bài viết này chúng ta sẽ cùng nhau tìm hiểu về Bounded Context trong DDD. Trước khi đi sâu vào khái niệm về Bounded Context trong DDD (Domain Driven Design), hãy cùng tìm hiểu ý nghĩa của nó trong thực tế ra sao

Chúng ta đều biết rằng con người là giống loài thông minh nhất và đã tạo ra các quốc gia khác nhau để cai trị. Nhưng câu hỏi là tại sao chúng ta tạo ra các quốc gia khác nhau hay ranh giới về mặt logic? Trên cơ sở nào ranh giới được đưa ra giữa 2 quốc gia, trước nền văn minh của loài người, trên trái đất chúng ta chỉ có đất và không có khái niệm về quốc gia.

Đáp án cho câu hỏi đó tôi nghĩ rằng nó được tách bởi những người cai trị, văn hoá, luật, kinh tế, nên mỗi quốc gia được trừu tượng hoá người dân của mình theo từng quốc gia khác nhau. Ngoài ra nó là việc bất khả thi để có thể tạo ra một văn hoá, ngôn ngữ đồng nhất giữa các quốc gia bởi vì trong thời cổ xưa các bộ tộc khác nhau sẽ có văn hoá và ngôn ngữ khác nhau.

Trong cùng một quốc gia, có những luật lệ được quy định, ngôn ngữ, phong cách mà tất cả người dân sẽ tuân theo. Để hiểu được ngôn ngữ chung, nhận thức về luật lệ, tiền tệ, phong cách nên chúng ta có thể hiểu đơn giản rằng người dân được đồng hoá trên từng quốc gia và một quốc gia sẽ có một văn hoá riêng mà tất cả người dân sẽ hiểu và tuân theo.

Trong lập trình, chúng ta áp dụng Bounded Context với cách thức tương tự để tách các Model hay Subdomain ra khỏi nhau trong phần Domain hay các bài toán. Trong Domain Driven Design, phần Stategic Design, chúng ta cũng đã được giới thiệu về Bounded Context, vì vậy trong một mô hình Context nhất định có một ý nghĩa nhất định giống như các quốc gia: ngôn ngữ và tiền tệ nhất định có một ý nghĩa cụ thể, nhưng đối với một quốc gia khác thì ngôn ngữ và tiền tệ này sẽ không hiểu được bởi vì nó không có ý nghĩa liên quan đến quốc gia đó.

Nên nếu chúng ta coi một quốc gia như Bounded Context, ngôn ngữ và tiền tệ như một Model bên trong Context đó chúng ta có thể dễ dàng hình dung ra ý nghĩa của Domain model trong một Bounded Context nhất định. Nên bằng việc sử dụng Bounded Context, chúng ta tạo một ranh giới logic nơi các Model và giới hạn nghiệp vụ có một ý nghĩa nhất định và Bounded Context tách / ẩn các Model với thế giới bên ngoài. Tất cả các trao đổi nên thông qua API. Nên nó khá rõ ràng rằng dưới Bounded Context các Model và logic nghiệp vụ cung cấp một luật nhất định, và cung cấp các lưu trữ của chính nó, và không được truy cập trực tiếp từ các Bounded Context khác

Giao tiếp giữa Bounded Context

Bất kỳ thiết kế nào cũng có 2 phần chung: trừu tượng hoá của Model dữ liệu và trao đổi thông tin giữa các phần của hệ thống. Bằng việc sử dụng Bounded Context, chúng ta có thể phân chia Model dữ liệu trong một thuật ngữ đơn giản trừu tượng hoá các điểm chung trong nghiệp vụ nhưng làm cách nào để các Bounded Context giao tiếp với nhau?

Ở đây khái niệm Context Map được đưa vào, dựa vào Context Map để hiểu được cách một Context dựa trên Bounded Context khác, giống như là 2 Context có phụ thuộc mạnh mẽ lẫn nhau, hay một Domain gửi một thông báo xác nhận đến một Domain khác (Conformist) hoặc có thể sử dụng shared kernel/Shared model.

Ví dụ

Tiếp theo chúng ta thiết kế một hệ thống quản lý sinh viên Online, nơi mà sinh viên có thể đăng ký các khoá học phù hợp online, thanh toán tiền học, sau đó được gắn vào một thẻ cho môt khoá học, giáo viên và học sinh được thông báo khi nào bắt đầu và thời gian học.

Tiếp theo bạn sẽ cần xác định Bounded Context của các Domain khác nhau liên quan đến logic nghiệp vụ. Chúng ta chia các logic nghiệp vụ, dựa trên các chức năng liên quan, chúng ta có thể chia thành 4 chức năng chính:

1. Registration – Xử lý đăng ký: Sinh viên đăng ký khoá học
2. Payment – Hệ thống thanh toán: Xử lý học phí và đưa ra trạng thái thanh toán online
3. Scheduler – Lập lịch khoá học: Sau khi xác nhận thanh toán, chức năng sẽ kiểm tra giáo viên khả dụng, khoá học khả dụng và dựa trên đó tạo một khoá học và gán các ứng viên hoặc cập nhập khoá học tồn tại với ứng viên.
4. Notification – Hệ thống thông báo: Nó sẽ thông báo cho giáo viên và học sinh thông tin về thời gian và địa điểm.

Do đó, có 4 Bounded Context: Registration, Payments, Scheduler, và Notification. Nào hãy cùng nhau đi sâu vào tìm hiểu từng module.

Registration

Context chỉ muốn thông tin của sinh viên (Student) và cần thông tin chi tiết khác như là tên – Name, tuổi – age, giới tính – sex, địa chỉ – address và khoá học sinh viên chọn.

Giáo viên không có ý nghĩa trong Context này.

Payment

Context coi các sinh viên như các ứng viên trong hệ thống thanh toán, chỉ yêu cầu thông tin thanh toán của ứng viên / sinh viên như là số tài khoản, và dựa trên chi phí khoá học hệ thống sẽ trừ tiền từ tài khoản. Vì vậy, ở đây góc nhìn về một sinh viên là khác nhau, thông tin cần thiết trong Service thanh toán là hoàn toàn khác nhau khi đăng ký (Registration) mặc dù hệ thống thanh toán chỉ cần một vài thông tin như là tên, địa chỉ sinh viên (là những thông tin cần thiết tối thiểu).

Thuật ngữ giáo viên (Teacher) không hợp lệ ở đây, trong hệ thống thanh toán Teacher (giáo viên) được coi như là Faculty (ngành học), họ có thể là dài hạn hoặc hợp đồng dựa trên kiểu hệ thống thanh toán của ngành học lựa chọn cách tính thanh toán cơ bản theo giờ hoặc theo năm.

Scheduler

Trong hệ thống lập kế hoach cho khoá học, nó cần thông tin tối thiểu từ giáo viên và học sinh như là tên, địa chỉ…Nhưng nó cần thông tin đầy đủ, tất nhiên, hàng loạt theo các khoá học.

Notification

Đối với hệ thống cảnh bảo, chúng ta cần địa chỉ email của giáo viên và học sinh, hoặc tên, số điện thoại…và nó cần tên hệ thống quản lý sinh viên và chi tiết khoá học. Ở đây phần quản lý nhân viên hoạt động như bên gửi (Sender), học sinh và giáo viên coi như là phía nhận (Receiver).

Bounded Context

Như bên trên chúng ta có thể thấy, cùng một Domain Object Teacher, Student và Course có ý nghĩa khác nhau và được sử dụng cho các Context khác nhau. Chúng ta có nhiều Model chính cho Object Domain giống nhau dựa trên Context khác nhau. Nên lập trình viên, (PO) nghiệp vụ, người sử dụng luôn luôn hiểu giống nhau khi nói về một Context, khái niệm về UL (Ubiquitous Language) được đan lại với nhau ở đây, và sử dụng UL trong DDD để tạo thành một hệ thống đồng nhất nơi tất cả những người tham gia đều hiểu được ngôn ngữ dựa trên Context.