Business Rules: Tách rời khỏi quy trình và DMN

1. Thách thức của các Quy tắc nghiệp vụ bên trong Quy trình

Hãy tưởng tượng một quy trình nghiệp vụ không phải lúc nào cũng đi theo một "luồng hạnh phúc" (happy path) duy nhất. Nó thường chứa đầy các điểm quyết định. Ví dụ:

• Phê duyệt khoản vay: Dựa trên điểm tín dụng, thu nhập, lịch sử vay.
• Tính phí vận chuyển: Dựa trên trọng lượng gói hàng, khoảng cách, loại dịch vụ.
• Xác định mức giảm giá: Dựa trên loại khách hàng, giá trị đơn hàng, các chương trình khuyến mãi hiện tại.

Với kinh nghiệm lập trình, bạn có thể nghĩ ngay đến việc sử dụng các Exclusive Gateway và thể hiện các quy tắc này bằng các biểu thức điều kiện, giống như một chuỗi if-else lồng nhau.

Đối với các quy tắc đơn giản, cách tiếp cận này hoàn toàn ổn. Nhưng khi các quy tắc trở nên phức tạp, mô hình BPMN của bạn có thể trông như thế này:

Việc nhúng logic phức tạp vào quy trình như trên gây ra một số vấn đề lớn:

• Khó đọc và phức tạp: Sơ đồ quy trình trở nên lộn xộn, làm lu mờ đi luồng nghiệp vụ chính. Rất khó để một người mới nhìn vào và hiểu được tổng thể quy trình.
• Khó bảo trì: Mỗi khi một quy tắc thay đổi (ví dụ: "Mùa đông, nếu khách ít hơn 8 người thì đổi sang món khác"), bạn phải tìm đúng gateway, chỉnh sửa điều kiện, và có thể phải deploy lại toàn bộ ứng dụng.
• Phụ thuộc vào Developer: Các quy tắc nghiệp vụ thường do các nhà phân tích nghiệp vụ (Business Analysts) hoặc các phòng ban khác định nghĩa. Khi các quy tắc này nằm trong code hoặc trong các biểu thức phức tạp của BPMN, mọi thay đổi dù là nhỏ nhất cũng cần đến sự can thiệp của developer. Điều này làm chậm quá trình kinh doanh.

2. DMN: Tách biệt Quy trình và Quyết định

Để giải quyết những thách thức trên, Camunda và cộng đồng BPM đã giới thiệu một tiêu chuẩn có tên là DMN (Decision Model and Notation).

DMN là một tiêu chuẩn toàn cầu để mô hình hóa và thực thi các quyết định nghiệp vụ. Thay vì nhúng các quy tắc vào sơ đồ quy trình, DMN cho phép bạn tách chúng ra một thành phần riêng, thường được biểu diễn dưới dạng các bảng quyết định (decision tables).

Nguyên tắc cốt lõi ở đây là sự tách biệt về mối quan tâm (separation of concerns):

• BPMN (Quy trình): Xác định trình tự các bước công việc. Nó trả lời câu hỏi "Tiếp theo cần làm gì?".
• DMN (Quyết định): Xác định logic để đưa ra một quyết định cụ thể tại một bước nào đó. Nó trả lời câu hỏi "Kết quả của quyết định này là gì dựa trên các dữ liệu đầu vào?".

Trong BPMN, bạn sẽ sử dụng một loại task đặc biệt gọi là Business Rule Task để gọi đến một quyết định DMN.

3. Các Tiêu chí để Quyết định sử dụng DMN

Vậy, với vai trò là một developer hay một kiến trúc sư hệ thống, khi nào bạn nên quyết định tách các quy tắc nghiệp vụ ra khỏi quy trình và sử dụng DMN? Dưới đây là một số tiêu chí quan trọng để bạn cân nhắc.

Tiêu chí 1: Độ phức tạp của Quy tắc

Nếu logic quyết định của bạn chỉ là một câu lệnh if-then-else đơn giản, việc dùng gateway có thể là đủ. Nhưng khi bạn có:

• Nhiều điều kiện đầu vào (input variables).
• Nhiều quy tắc (rules) kết hợp các điều kiện đó.
• Các quy tắc tạo thành một ma trận logic phức tạp.

...thì đó là lúc DMN tỏa sáng. Việc biểu diễn logic này dưới dạng một bảng quyết định sẽ rõ ràng và dễ quản lý hơn nhiều so với một mạng lưới gateway chằng chịt.

Tiêu chí 2: Tần suất Thay đổi

Hãy tự hỏi: "Các quy tắc nghiệp vụ này có thay đổi thường xuyên không?".

• Ví dụ: Các quy tắc về giá cả, chính sách khuyến mãi, tiêu chí đánh giá rủi ro tín dụng thường thay đổi theo quý, theo tháng, hoặc thậm chí hàng ngày để phản ứng với thị trường.
• Ngược lại, luồng quy trình tổng thể (ví dụ: Nhận đơn hàng -> Xử lý thanh toán -> Giao hàng -> Hoàn tất) thường ổn định hơn nhiều.

Nếu các quy tắc thay đổi thường xuyên, việc tách chúng ra DMN cho phép các nhà phân tích nghiệp vụ tự cập nhật bảng quyết định mà không cần deploy lại mã nguồn, giúp doanh nghiệp trở nên linh hoạt hơn.

Tiêu chí 3: Chủ sở hữu của Quy tắc

Ai là người chịu trách nhiệm về các quy tắc này?

• Nếu các quy tắc do đội ngũ kinh doanh, tài chính, hoặc pháp chế định nghĩa và sở hữu, thì việc để chúng ở định dạng mà họ có thể đọc, hiểu và thậm chí tự chỉnh sửa (như bảng DMN) sẽ hiệu quả hơn nhiều so với việc "dịch" chúng sang mã Java hay các biểu thức kỹ thuật. DMN đóng vai trò là "ngôn ngữ chung" giữa nghiệp vụ và IT.

Tiêu chí 4: Khả năng Tái sử dụng

Một bộ quy tắc quyết định (ví dụ: "đánh giá mức độ rủi ro của khách hàng") có thể được sử dụng ở nhiều nơi khác nhau: trong quy trình mở tài khoản, quy trình duyệt khoản vay, quy trình phát hành thẻ tín dụng.

• Bằng cách đóng gói logic này vào một quyết định DMN, bạn có thể gọi nó từ nhiều quy trình BPMN khác nhau, giống như gọi một hàm hoặc một microservice có thể tái sử dụng.

4. Các Trường hợp sử dụng Phổ biến

Để bạn dễ hình dung, đây là một số kịch bản thực tế mà DMN thường được áp dụng:

• Xác định điều kiện hưởng quyền (Eligibility Determination):
  • Một khách hàng có đủ điều kiện vay vốn không? (Dựa trên điểm tín dụng, thu nhập, tình trạng việc làm)
  • Một công dân có đủ điều kiện nhận trợ cấp xã hội không?
• Giá cả và Giảm giá (Pricing and Discounts):
  • Tính giá cước vận chuyển cho một đơn hàng.
  • Xác định mức giảm giá cho khách hàng VIP, khách hàng thân thiết, hay trong các đợt khuyến mãi.
• Quản lý Rủi ro (Risk Management):
  • Đánh giá mức độ rủi ro của một đơn xin bảo hiểm.
  • Phát hiện giao dịch đáng ngờ trong hệ thống ngân hàng.

Trong tất cả các trường hợp này, các quy tắc thường phức tạp, thay đổi theo thời gian và được định nghĩa bởi các chuyên gia nghiệp vụ, làm cho chúng trở thành những ứng cử viên hoàn hảo để quản lý bằng DMN.

Tổng kết

Qua bài học này, bạn đã học được một trong những nguyên tắc thiết kế quan trọng nhất khi làm việc với BPM: khi nào nên giữ logic trong quy trình và khi nào nên tách nó ra.

Những điểm chính cần ghi nhớ:

• Việc nhúng các quy tắc nghiệp vụ phức tạp vào quy trình BPMN bằng gateways sẽ làm quy trình khó đọc, khó bảo trì và kém linh hoạt.
• DMN (Decision Model and Notation) là một tiêu chuẩn để tách biệt các quy tắc nghiệp vụ ra khỏi luồng quy trình, giúp quản lý chúng một cách độc lập.
• Hãy cân nhắc sử dụng DMN khi các quy tắc của bạn có độ phức tạp cao, thay đổi thường xuyên, thuộc quyền sở hữu của bộ phận nghiệp vụ, hoặc cần được tái sử dụng ở nhiều nơi.
• Việc tách biệt này giúp quy trình của bạn sạch sẽ, dễ hiểu và cho phép doanh nghiệp phản ứng nhanh hơn với các thay đổi.

Xem trước bài học tiếp theo

Bây giờ bạn đã hiểu tại sao và khi nào nên sử dụng DMN. Trong bài học tiếp theo, chúng ta sẽ chuyển từ lý thuyết sang thực hành. Bạn sẽ được hướng dẫn từng bước để tạo một Bảng Quyết định (Decision Table) trong Camunda Modeler, định nghĩa các đầu vào, đầu ra, và các quy tắc để giải quyết một bài toán nghiệp vụ cụ thể.