Mở đầu — vì sao bài này quan trọng
Hãy tưởng tượng bạn vừa viết xong một User Story rất đẹp: "Là khách hàng, tôi muốn được giảm giá khi mua hàng để tiết kiệm chi phí." Nghe rất ổn. Nhưng đến lúc developer ngồi code, họ quay sang hỏi bạn: "Giảm bao nhiêu phần trăm? Áp dụng cho đơn hàng từ bao nhiêu tiền? Khách VIP có được cộng dồn không? Đơn đã giảm rồi có được dùng thêm mã coupon không?"
Đây chính là khoảng trống mà business rule (quy tắc nghiệp vụ) lấp vào. User Story nói cái gì và tại sao, còn business rule nói chính xác điều kiện logic mà hệ thống phải tuân theo. Nếu bạn không quản lý chúng một cách có hệ thống, những quy tắc này sẽ nằm rải rác — trong đầu chị kế toán, trong một email cũ, trong một comment code, trong trí nhớ của anh trưởng phòng đã nghỉ việc. Và rồi một ngày, không ai còn nhớ tại sao hệ thống lại tính tiền như vậy.
Là một BA fresher, kỹ năng viết và quản lý business rule catalog (danh mục quy tắc nghiệp vụ) sẽ khiến bạn khác biệt ngay lập tức. Nó cho thấy bạn không chỉ chép lại lời stakeholder, mà bạn cấu trúc hóa được logic nghiệp vụ thành thứ có thể tra cứu, kiểm thử và bảo trì. Trong bài này, chúng ta sẽ đi từ định nghĩa, 4 loại business rule, cách viết một catalog thực tế, cho đến những lỗi kinh điển mà người mới hay mắc.
Khái niệm cốt lõi
Business rule là gì?
Business rule là một câu lệnh xác định hoặc ràng buộc một khía cạnh của nghiệp vụ. Nó là điều kiện logic mà tổ chức tự đặt ra (không phải luật vật lý, không phải quy luật tự nhiên) và hệ thống phải tuân thủ. Điểm mấu chốt: business rule tồn tại độc lập với hệ thống phần mềm — dù bạn làm bằng phần mềm, bằng Excel hay bằng giấy bút, quy tắc "khách VIP được miễn phí ship với đơn trên 200.000đ" vẫn đúng.
Một business rule tốt phải:
- Nguyên tử (atomic): chỉ diễn tả một điều, không gộp nhiều logic.
- Diễn đạt được bằng lời: người nghiệp vụ đọc phải hiểu, không cần biết code.
- Có thể kiểm thử được: bạn phải trả lời được đúng/sai với một tình huống cụ thể.
- Không mâu thuẫn với các rule khác trong catalog.
4 loại business rule
Đây là phần xương sống. Có nhiều cách phân loại, nhưng cách phổ biến và dễ dùng nhất cho BA fresher là chia làm 4 nhóm:
1. Definition (Định nghĩa / Terms) — Quy tắc định nghĩa một thuật ngữ hoặc phân loại. Nó trả lời câu hỏi "cái này nghĩa là gì?". > Ví dụ: "Khách hàng VIP là khách hàng có tổng chi tiêu trong 12 tháng gần nhất từ 20.000.000đ trở lên."
Đây là rule quan trọng bậc nhất nhưng hay bị bỏ quên. Nếu không định nghĩa rõ "VIP", thì mọi rule khác dùng từ "VIP" đều mơ hồ.
2. Fact (Sự kiện / Quan hệ) — Quy tắc mô tả mối quan hệ giữa các khái niệm, một sự thật luôn đúng trong nghiệp vụ. > Ví dụ: "Mỗi đơn hàng phải thuộc về đúng một khách hàng." / "Một khách hàng có thể có nhiều địa chỉ giao hàng."
Fact thường trở thành nền tảng cho data model và ERD (bạn đã học ở Bài 37). Chúng định hình cấu trúc dữ liệu.
3. Constraint (Ràng buộc) — Quy tắc bắt buộc hoặc cấm một hành động, thường có dạng "phải", "không được", "chỉ khi". Đây là loại nhiều nhất và hay gây bug nếu bỏ sót. > Ví dụ: "Không được hủy đơn hàng đã ở trạng thái 'Đang giao'." / "Mật khẩu phải có tối thiểu 8 ký tự, gồm ít nhất 1 chữ hoa và 1 số."
4. Derivation (Suy diễn / Tính toán) — Quy tắc tính ra một giá trị từ các giá trị khác, gồm cả công thức tính toán và suy luận logic. > Ví dụ: "Tổng tiền đơn hàng = tổng (đơn giá × số lượng) từng dòng sản phẩm − giảm giá + phí ship + VAT 10%." / "Nếu khách hàng có điểm tín dụng dưới 500 thì phân loại là 'rủi ro cao'."
Mẹo nhớ nhanh: Đ-S-R-T — Định nghĩa, Sự kiện, Ràng buộc, Tính toán. Khi phỏng vấn stakeholder, bạn tự hỏi từng câu họ nói thuộc loại nào — điều này giúp bạn đặt câu hỏi đào sâu đúng hướng.
Business rule khác gì với requirement?
Đây là nhầm lẫn kinh điển. Requirement nói hệ thống cần làm gì ("hệ thống cho phép khách nhập mã giảm giá"). Business rule nói logic đằng sau ("mã giảm giá chỉ áp dụng một lần cho mỗi khách, và không cộng dồn với chương trình flash sale"). Một requirement thường tham chiếu đến nhiều business rule. Vì thế trong tài liệu, ta thường gán mỗi rule một mã (BR-001, BR-002...) rồi trong User Story hoặc acceptance criteria ta trỏ đến mã đó, thay vì viết lại toàn bộ logic.
Tình huống thực tế
Ví dụ 1 — Sàn thương mại điện tử Tiki và cơn ác mộng khuyến mãi cộng dồn
Một BA fresher tên Linh làm cho một sàn e-commerce (giả định theo mô hình Tiki/Lazada). Đội marketing tung một chiến dịch: giảm 15% cho khách mới, cộng thêm mã freeship 30.000đ, cộng thêm hoàn 5% xu. Trong sprint đầu, Linh chỉ viết User Story chung chung mà không tách business rule. Kết quả: khi hệ thống lên production, một số khách gộp cả ba ưu đãi cộng thêm voucher sinh nhật, dẫn đến có đơn giá trị 500.000đ nhưng khách chỉ trả 180.000đ. Chỉ trong 6 tiếng, công ty lỗ ước tính hơn 40 triệu đồng trước khi kịp tắt chương trình.
Diễn giải: Vấn đề nằm ở việc thiếu các constraint rõ ràng về khả năng cộng dồn (stacking). Sau sự cố, Linh ngồi lại và viết ra catalog:
- BR-101 (Constraint): Mỗi đơn hàng chỉ áp dụng tối đa một mã giảm giá theo phần trăm.
- BR-102 (Constraint): Mã freeship có thể cộng dồn với mã giảm giá phần trăm, nhưng không cộng dồn với ưu đãi freeship từ hạng thành viên.
- BR-103 (Definition): "Khách mới" là tài khoản có 0 đơn hàng hoàn tất trong lịch sử.
Ví dụ 2 — Ngân hàng số và định nghĩa "giao dịch đáng ngờ"
Một BA fresher ở một ngân hàng số tại Việt Nam (giả định mô hình Timo/Cake) được giao viết rule cho tính năng cảnh báo gian lận. Team compliance nói: "Chặn các giao dịch đáng ngờ." BA junior này suýt viết luôn requirement "hệ thống chặn giao dịch đáng ngờ" — nhưng may là bạn ấy dừng lại và hỏi: "'Đáng ngờ' nghĩa là gì?"
Sau ba buổi họp, catalog ra đời:
- BR-210 (Definition): Giao dịch đáng ngờ là giao dịch thỏa MỘT trong các điều kiện: (a) số tiền ≥ 100.000.000đ trong một lần, hoặc (b) tổng chuyển trong 24h ≥ 300.000.000đ, hoặc (c) chuyển đến tài khoản mới thêm dưới 24h.
- BR-211 (Derivation): Điểm rủi ro = 40×(số điều kiện thỏa) + 20×(nếu giao dịch ngoài giờ 22h–6h).
- BR-212 (Constraint): Giao dịch có điểm rủi ro ≥ 60 phải được giữ lại chờ xác thực OTP lần hai.
Bài học: Trong domain banking, một từ mơ hồ như "đáng ngờ", "bất thường", "hợp lệ" luôn phải được truy về một Definition có con số cụ thể. Đây cũng là lý do BA ngân hàng được trả lương cao — họ biến ngôn ngữ mơ hồ thành logic kiểm thử được.
Ví dụ 3 — Chuỗi cà phê và bài toán tích điểm thành viên
Một chuỗi cà phê (giả định mô hình Highlands/The Coffee House) muốn số hóa chương trình thành viên. BA fresher tổng hợp rule từ phòng marketing, và phát hiện các quản lý cửa hàng đang hiểu quy tắc khác nhau. Cửa hàng A cho tích điểm cả đồ ăn kèm, cửa hàng B chỉ tích điểm đồ uống. Đây chính là dấu hiệu business rule chưa được quản lý tập trung.
Catalog thống nhất:
- BR-301 (Derivation): Điểm tích lũy = làm tròn xuống (tổng tiền thanh toán sau giảm giá / 1.000).
- BR-302 (Constraint): Không tích điểm cho phần hóa đơn thanh toán bằng chính điểm thưởng đã đổi.
- BR-303 (Fact): Mỗi hóa đơn gắn với đúng một tài khoản thành viên tại thời điểm thanh toán.
Hướng dẫn từng bước
Dưới đây là quy trình 6 bước để xây một business rule catalog từ zero.
Bước 1 — Thu thập rule từ nhiều nguồn. Đừng chỉ nghe một người. Nguồn rule gồm: phỏng vấn stakeholder, tài liệu chính sách hiện có, quan sát hệ thống cũ đang chạy, và cả các trường hợp ngoại lệ mà nhân viên đang xử lý thủ công. Ghi lại thô, chưa cần đẹp.
Bước 2 — Phân loại theo Đ-S-R-T. Với mỗi câu bạn ghi được, gán nó vào Definition, Fact, Constraint hay Derivation. Việc phân loại giúp bạn phát hiện lỗ hổng: nếu bạn có nhiều Constraint dùng từ "VIP" mà chưa có Definition cho "VIP", bạn biết ngay mình còn thiếu.
Bước 3 — Viết mỗi rule theo chuẩn nguyên tử. Tách một câu ghép thành nhiều rule đơn. Câu "Khách VIP được freeship và giảm 10% nhưng không quá 50.000đ" thực chất là 3 rule: một freeship, một tỷ lệ giảm, một trần giảm.
Bước 4 — Gán mã và thuộc tính. Mỗi rule cần một ID duy nhất (BR-001...) và các cột thông tin. Một bảng catalog tối thiểu nên có các cột:
| Cột | Ý nghĩa |
|---|---|
| ID | Mã duy nhất, ví dụ BR-101 |
| Tên/Mô tả | Câu rule viết bằng ngôn ngữ nghiệp vụ |
| Loại | Definition / Fact / Constraint / Derivation |
| Nguồn | Ai/tài liệu nào cung cấp rule này |
| Trạng thái | Draft / Approved / Deprecated |
| Liên quan | Trỏ tới User Story, requirement, rule khác |
| Ngày cập nhật | Để lần dấu thay đổi |
Bước 6 — Duyệt, phiên bản hóa và liên kết. Đưa catalog cho stakeholder duyệt (đổi trạng thái sang Approved), lưu trên công cụ tập trung (Confluence, Notion, hoặc một sheet chung), và liên kết mã rule vào User Story/acceptance criteria. Từ đó về sau, khi rule thay đổi, bạn sửa ở một chỗ và mọi tài liệu tham chiếu đều biết.
Về công cụ: với dự án nhỏ, một Google Sheet có bộ lọc là đủ. Với dự án lớn hơn, dùng một trang Confluence chứa bảng rule, hoặc Notion database có thể filter theo loại/trạng thái. Điều quan trọng không phải công cụ xịn, mà là chỉ có một nơi duy nhất chứa sự thật.
Lỗi thường gặp & mẹo
Lỗi 1 — Gộp nhiều logic vào một rule. Người mới hay viết rule dài ba dòng với đủ "nếu... và... trừ khi...". Điều này khiến rule không thể kiểm thử và khó bảo trì. Mẹo: một rule = một câu khẳng định đúng/sai được.
Lỗi 2 — Nhúng rule vào code mà không tài liệu hóa. Developer để "magic number" (số 15% giảm giá) thẳng trong code. Sáu tháng sau không ai nhớ vì sao là 15%. Mẹo: mọi con số nghiệp vụ đều phải có một rule tương ứng trong catalog, để khi marketing đổi thành 20% thì bạn biết đổi ở đâu.
Lỗi 3 — Quên định nghĩa (Definition). Viết đầy Constraint dùng thuật ngữ mà chưa định nghĩa thuật ngữ đó. Mẹo: luôn bắt đầu catalog bằng nhóm Definition — nó là từ điển cho mọi rule còn lại.
Lỗi 4 — Không quản lý phiên bản. Sửa rule trực tiếp mà không ghi lại lịch sử. Khi có tranh chấp "trước đây tính khác mà", không ai chứng minh được. Mẹo: giữ cột ngày cập nhật và trạng thái Deprecated thay vì xóa hẳn rule cũ.
Lỗi 5 — Trộn business rule với business requirement. Viết "hệ thống phải hiển thị nút giảm giá" (đây là requirement) vào catalog rule. Mẹo: nếu câu nói về giao diện, luồng thao tác, hay tính năng — đó là requirement, không phải rule. Rule chỉ nói về logic nghiệp vụ.
Mẹo vàng: Với mỗi rule Constraint, hãy hỏi "điều gì xảy ra khi vi phạm?". Ví dụ "không được hủy đơn đang giao" — vậy khi khách bấm hủy thì hệ thống báo lỗi gì, ai được phép override? Câu trả lời thường sinh ra thêm rule mới mà bạn đã bỏ sót.
Bài tập thực hành
Hãy làm bài tập sau để biến lý thuyết thành phản xạ.
Đề bài: Một tiệm cho thuê xe máy du lịch ở Đà Nẵng (giả định "Đà Nẵng Motorbike Rental") muốn số hóa quy trình thuê xe. Bạn thu thập được các câu sau từ chủ tiệm:
- "Khách phải trên 18 tuổi mới được thuê."
- "Đặt cọc bằng 50% giá thuê, nhưng tối thiểu 200.000đ."
- "Khách thuê từ 7 ngày trở lên được giảm 10%."
- "Khách VIP là người đã thuê trên 5 lần."
- "Không cho thuê xe nếu chưa có bản chụp CMND/CCCD."
- "Phí trả xe trễ là 50.000đ mỗi giờ, tối đa bằng một ngày thuê."
- Gán mỗi câu vào một trong 4 loại (Đ-S-R-T). Lưu ý câu số 2 và số 6 có thể cần tách thành nhiều rule nguyên tử.
- Viết lại thành catalog với các cột: ID, Loại, Mô tả rule.
- Chỉ ra ít nhất một lỗ hổng trong danh sách trên — một Definition còn thiếu, hoặc một Constraint chưa rõ điều gì xảy ra khi vi phạm. (Gợi ý: câu số 3 giảm 10% dựa trên giá nào — trước hay sau cọc? Câu số 4 định nghĩa VIP nhưng VIP được ưu đãi gì?)
Làm xong, hãy tưởng tượng đưa catalog này cho một developer chưa biết gì về tiệm xe — nếu họ code được mà không cần hỏi lại, bạn đã viết đạt.
Tóm tắt
- Business rule là điều kiện logic nghiệp vụ mà hệ thống phải tuân thủ; nó tồn tại độc lập với phần mềm và phải nguyên tử, diễn đạt được, kiểm thử được.
- Có 4 loại (Đ-S-R-T): Definition (định nghĩa thuật ngữ), Fact (quan hệ/sự thật), Constraint (bắt buộc/cấm), Derivation (tính toán/suy diễn).
- Business rule khác requirement: rule nói logic, requirement nói hệ thống cần làm gì. Gán mã (BR-xxx) và trỏ từ User Story vào rule thay vì lặp lại logic.
- Catalog cần các cột tối thiểu: ID, mô tả, loại, nguồn, trạng thái, liên kết, ngày cập nhật — và phải là nguồn sự thật duy nhất.
- Quy trình 6 bước: thu thập → phân loại → viết nguyên tử → gán mã & thuộc tính → rà mâu thuẫn → duyệt & phiên bản hóa.
- Lỗi hay gặp: gộp logic, nhúng số vào code không tài liệu hóa, quên Definition, không quản lý phiên bản, trộn rule với requirement.