Business Rule — Từ luật nghiệp vụ đến Source of Truth cho AI

1. Business Rule là gì?

Trong quá trình phân tích nghiệp vụ, một trong những công việc quan trọng của BA là xác định:

Business thực sự đang vận hành theo những luật nào?

Business Rule là những quy tắc, chính sách, ràng buộc hoặc định nghĩa mà tổ chức đặt ra để kiểm soát hoặc định hướng hoạt động nghiệp vụ.

Ví dụ:

Khách hàng phải đủ 18 tuổi mới được mở tài khoản.

Một thành viên tiêu chuẩn không được có quá 5 khoản mượn đang hoạt động.

Một đơn hàng trên 500.000đ được miễn phí giao hàng.

Một tài khoản bị khóa không được thực hiện giao dịch.

Điểm quan trọng là Business Rule mô tả:

Business cho phép gì, yêu cầu gì, cấm gì hoặc định nghĩa một khái niệm như thế nào.

Nó không phụ thuộc vào việc hệ thống được xây bằng:

.NET
Java
Python
SQL Server
PostgreSQL
REST
GraphQL

2. Business Rule không phải là Code

Ví dụ business nói:

Thành viên thường không được mượn quá 5 cuốn sách đang hoạt động.

Business Rule:

BR-BOR-001

A standard member must not have more than 5 active loans.

Đây không phải:

if (member.ActiveLoans.Count >= 5)
{
    throw new BorrowingLimitExceededException();
}

Code chỉ là một cách hiện thực hóa rule.

Có thể sau này hệ thống thay đổi architecture:

Business Rule
      ↓
Domain Model
      ↓
Application Layer
      ↓
API

hoặc:

Business Rule
      ↓
Domain Service
      ↓
Message Handler

Business Rule vẫn giữ nguyên.

3. Business Rule vs Business Requirement

Đây là hai khái niệm rất dễ bị trộn lẫn.

Business Requirement

Thường trả lời:

Business muốn đạt được điều gì?

Ví dụ:

The library needs to allow members to borrow books.

Business Rule

Trả lời:

Hoạt động đó phải tuân theo những luật nào?

Ví dụ:

A standard member must not have more than 5 active loans.

A suspended member must not create a new loan.

A book copy must not have more than one active loan.

Có thể hình dung:

Business Goal
     ↓
Business Requirement
     ↓
Business Rules
     ↓
System Requirements
     ↓
Implementation

Một requirement có thể liên quan đến nhiều Business Rule.

4. Đừng nhầm Business Rule với "HOW"

Một điểm cần đặc biệt lưu ý.

Có tài liệu gọi:

Business Requirement = WHAT
Business Rule = HOW

Cách giải thích này khá dễ nhớ nhưng không thật sự chính xác về bản chất.

Ví dụ:

A standard member must not have more than 5 active loans.

đây không phải "HOW system implements borrowing".

Nó chỉ nói:

Business đặt ra constraint nào.

Còn HOW của software có thể là:

Domain Policy
Application Service
Database Constraint
Validation

Do đó tốt hơn nên nhớ:

Business Requirement
→ Business muốn đạt điều gì?

Business Rule
→ Business hoạt động theo luật nào?

System Requirement
→ System phải làm gì để đáp ứng?

Design
→ Chúng ta xây system như thế nào?

5. Business Rule tốt có đặc điểm gì?

Không có một syntax duy nhất bắt buộc mọi tổ chức phải dùng.

Tuy nhiên, trong thực tế, một Business Rule tốt thường có các đặc điểm sau.

5.1. Declarative

Mô tả luật, không mô tả procedure.

Không tốt

When the user clicks Borrow,
the system checks the number of active loans,
then calls the borrowing service.

Đây là process/implementation.

Tốt

A standard member must not have more than 5 active loans.

5.2. Atomic

Một rule nên tập trung vào một constraint hoặc một proposition.

Không tốt

A customer must be over 18, have a valid ID,
have a verified phone number and earn at least
10 million VND per month.

Tách thành:

BR-CUS-001
A customer must be at least 18 years old.

BR-CUS-002
A customer must have a valid identity document.

BR-CUS-003
A customer's phone number must be verified.

BR-CUS-004
A customer must have a monthly income of at least
10 million VND.

Khi đó mỗi rule có thể:

• trace;

• test;

• thay đổi;

• review;

• reuse.

6. Business Rule phải testable

Một rule tốt phải cho phép team xác định:

Nếu xảy ra tình huống X thì rule có được thỏa mãn hay không?

Ví dụ:

BR-BOR-001

A standard member must not have more than 5 active loans.

Ta có:

Active loans = 4 → Allowed
Active loans = 5 → Allowed
Active loans = 6 → Rejected

Từ đó có thể tạo Acceptance Criteria:

Given a standard member has 5 active loans
When the member attempts to borrow another book
Then the borrowing request is rejected

Và cuối cùng:

BorrowBook_WhenMemberHasFiveActiveLoans_ShouldReject()

Chuỗi rất đẹp:

Business Rule
      ↓
Acceptance Criteria
      ↓
Test

7. Các loại Business Rule

Thay vì chỉ phân loại theo "Constraint / Computation / Process / Data", mình khuyên bài của bạn phân biệt bản chất của rule.

Constraint

A standard member must not have more than 5 active loans.

Prohibition

A suspended member must not create a new loan.

Permission

A premium member may borrow up to 10 active books.

Definition

An active loan is a loan that has not been returned.

Structural

A physical book copy belongs to exactly one book title.

Derivation

A loan is overdue when its due date has passed
and the loan has not been returned.

State Transition

When a loan is returned,
the associated book copy becomes available.

Không phải rule nào cũng cần viết bằng:

IF ... THEN ...

IF/THEN chỉ là một cách biểu diễn phù hợp cho một số loại rule.

8. Một Business Rule nên có ID

Khi project nhỏ, có thể viết:

A standard member must not have more than 5 active loans.

Nhưng project lớn sẽ rất nhanh gặp vấn đề:

Feature A nói giới hạn 5.

Feature B nói giới hạn 10.

Code A dùng 5.

Code B dùng 10.

Test C test 5.

Do đó Business Rule nên có identity:

BR-BOR-001

Convention đơn giản:

BR-<DOMAIN>-<NUMBER>

Ví dụ:

BR-BOR-001
BR-BOR-002

BR-MEM-001
BR-MEM-002

BR-RES-001

Một nguyên tắc quan trọng:

Rule ID không được tái sử dụng.

Nếu rule cũ bị bỏ:

BR-BOR-002
Status: Deprecated

không đổi thành rule khác.

9. Business Rule nên lưu ở đâu?

Đây là phần mình nghĩ nên khác đáng kể so với bài tham khảo.

Thay vì:

business-rules.xlsx

hoặc:

requirements.docx

mình khuyên với project hiện đại dùng Git:

docs/
└── business-rules/
    ├── README.md
    ├── book.md
    ├── membership.md
    ├── borrowing.md
    ├── reservation.md
    └── fine.md

Không phải vì Markdown là "chuẩn Business Rule".

Markdown chỉ là representation.

Lợi ích là:

Markdown
   +
Git
   +
Search
   +
Diff
   +
AI
   +
Traceability

10. README.md — Business Rule Catalog

# Business Rules

## Rule Catalog

| Domain | File | Rules | Status |
|---|---|---|---|
| Book | book.md | BR-BOOK-001 → 003 | Active |
| Membership | membership.md | BR-MEM-001 → 004 | Active |
| Borrowing | borrowing.md | BR-BOR-001 → 006 | Active |
| Reservation | reservation.md | BR-RES-001 → 003 | Active |
| Fine | fine.md | BR-FINE-001 → 004 | Active |

README.md là:

Catalog / Table of Contents

chứ không phải source of truth cho nội dung rule.

11. Mỗi Business Domain một file

Ví dụ:

borrowing.md

# Borrowing Business Rules

Rules governing borrowing and returning physical book copies.

## Rule Summary

| ID | Rule | Type | Status |
|---|---|---|---|
| BR-BOR-001 | Standard member ≤ 5 active loans | Constraint | Active |
| BR-BOR-002 | Premium member ≤ 10 active loans | Constraint | Active |
| BR-BOR-003 | Suspended member cannot borrow | Prohibition | Active |
| BR-BOR-004 | Overdue member cannot borrow | Prohibition | Active |

## Detailed Rules

...

Như vậy:

README
   ↓
Domain
   ↓
Summary
   ↓
Detailed Rule

12. Template của một Business Rule

Đây là template mình đề xuất cho project.

### BR-BOR-001 — Standard Member Borrowing Limit

**Status:** Active

**Type:** Constraint

**Owner:** Borrowing

**Rule:**

A standard member must not have more than 5 active loans.

**Source:**

Library borrowing policy.

**Rationale:**

Limit the number of books a standard member can
hold at the same time.

**Applies to:**

- Borrow Book
- Renew Loan

**Used by:**

- SPEC-003 — Borrow Book
- SPEC-013 — Renew Loan

**Effective from:**

2026-09-01

Không nhất thiết rule nào cũng phải có tất cả metadata.

Nguyên tắc:

Không biết thì để TBD, không được để AI tự bịa.

13. Business Rule phải có một Source of Truth

Đây là nguyên tắc rất quan trọng khi project có AI.

Không nên:

Word nói 5
Excel nói 5
Jira nói 10
Specification nói 10
Code nói 5

AI lúc này không thể biết đâu là authoritative source.

Nên xác định:

Business Rule Repository
        ↓
      Source
      of Truth

Các artifact khác reference nó:

Business Rule
      ↑
      │
Specification
      │
      ↓
Acceptance Criteria
      ↓
Test
      ↓
Code

14. Traceability

Ví dụ:

BR-BOR-001
        │
        ├── SPEC-003
        ├── SPEC-013
        ├── SPEC-021
        │
        ├── Test-BOR-001
        └── BorrowingPolicy

Khi Business thay đổi:

5 → 7 active loans

không nên chỉ:

Search "5"
→ sửa code

Mà phải:

Business Change
      ↓
BR-BOR-001
      ↓
Find usages
      ↓
Affected Specifications
      ↓
Acceptance Criteria
      ↓
Tests
      ↓
Code

Business Rule lúc này trở thành một anchor cho impact analysis.

15. Khi Business Rule conflict

Đây là nơi AI có thể hỗ trợ rất tốt.

Giả sử:

BR-BOR-001

A standard member must not have more than 5 active loans.

Specification mới lại nói:

A standard member may have up to 10 active loans.

AI không được tự chọn.

Nó phải báo:

CONFLICT DETECTED

Existing Business Rule:
BR-BOR-001
A standard member must not have more than 5 active loans.

New Specification:
A standard member may have up to 10 active loans.

These statements conflict.

Please confirm whether BR-BOR-001
should be changed from 5 to 10.

Đây là một nguyên tắc rất quan trọng:

AI nên phát hiện conflict, không nên tự quyết định business policy.

16. Business Rule và AI

Đây chính là phần có thể làm bài viết của bạn khác biệt so với các bài BA truyền thống.

AI không nên được dùng như:

"AI, hãy nghĩ giúp tôi các Business Rule."

AI có thể suy đoán, nhưng business rule là business policy.

Thay vào đó:

Business / SME
      ↓
Business Policy
      ↓
BA + AI
      ↓
Extract / Structure / Validate
      ↓
Business Rule Repository
      ↓
AI
      ↓
Specification / Plan / Code / Test

AI có thể giúp:

• extract rule từ tài liệu;

• tìm duplicate;

• tìm conflict;

• chuẩn hóa wording;

• tạo Rule ID;

• cập nhật catalog;

• tìm specification sử dụng rule;

• tạo acceptance criteria;

• tạo test cases;

• impact analysis.

Nhưng:

Business vẫn là authority đối với business policy.

17. Prompt để tạo Business Rule

Có thể chuẩn hóa thành một prompt/command:

Create or update Business Rules for this feature.

Source:
docs/features/003-borrow-book/spec.md

Existing Business Rules:
docs/business-rules/

Rules:

1. Do not invent business rules.
2. Search existing rules before creating new ones.
3. Reuse an existing rule when applicable.
4. Do not create duplicate rules.
5. Preserve existing Rule IDs.
6. Detect and report conflicts.
7. Keep rules declarative and technology independent.
8. Make each rule atomic and testable.
9. Update the appropriate domain file.
10. Update the Business Rule catalog.

If the source contains insufficient information,
mark it as TBD or ask for clarification.

Do not silently resolve conflicts.

Đây là nơi bạn có thể đưa vào workshop:

AI không chỉ generate nội dung. Prompt còn định nghĩa governance cho tài liệu.

18. Business Rule không nên over-engineer

Với một hệ thống như Library Management System, không nhất thiết phải dùng:

Rule Engine
BRMS
SBVR
Formal Logic
Ontology

Ngay từ đầu.

Một cấu trúc:

Markdown
+
Git
+
Rule ID
+
Catalog
+
Traceability

đã có thể rất hiệu quả.

Khi số lượng rule lớn hoặc rule cần runtime configuration, lúc đó mới cân nhắc những giải pháp chuyên biệt.

19. Checklist

Trước khi một Business Rule được xem là hoàn chỉnh:

□ Có một ý chính?
□ Declarative?
□ Dùng domain language?
□ Không chứa implementation?
□ Cụ thể?
□ Testable?
□ Không mơ hồ?
□ Có Rule ID?
□ Không duplicate?
□ Không conflict?
□ Có source?
□ Có owner?
□ Biết feature nào sử dụng?
□ Có status?
□ Có effective date nếu cần?

20. Kết luận

Business Rule không phải là một đoạn validation trong code.

Nó là luật của business, được đưa vào một dạng có thể quản lý được để cả BA, PO, Developer, Tester và AI cùng tham chiếu.

Có thể nhớ bằng chuỗi:

🏢 Business
     ↓
📕 Business Rule
     ↓
📋 Specification
     ↓
📐 Plan
     ↓
📋 Tasks
     ↓
💻 Code
     ↓
🧪 Test

Và trong AI-assisted development:

             📕 Business Rule
                    │
             Source of Truth
                    │
        ┌───────────┼───────────┐
        ↓           ↓           ↓
       Spec        Test        Code
        │           │           │
        └───────────┼───────────┘
                    ↓
                   AI

Đừng để AI "nhớ" Business Rule. Hãy để AI đọc Business Rule từ một Source of Truth có cấu trúc, có ID và có traceability.

Một chỉnh sửa mình đặc biệt khuyên cho bài tham khảo

Phần phân biệt này:

Business Requirement = WHAT
Business Rule = HOW

mình sẽ không giữ nguyên trong bài của bạn.

Thay bằng:

Business Requirement
→ Business muốn đạt được điều gì?

Business Rule
→ Business hoạt động theo những luật nào?

System Requirement
→ System phải làm gì?

Design / Plan
→ Chúng ta xây system như thế nào?

Nó sẽ khớp hơn với chuỗi Business Rule → Constitution/ADR → Specification → Plan → Code mà bạn đang xây cho cả series, và tránh cho người đọc sau này nhầm Business Rule với technical design/implementation.