Kỹ Nghệ Ngữ Cảnh Theo Chuẩn Domain-Driven Design

Một trong những sai lầm thảm họa nhất của các kỹ sư khi mới chuyển sang dùng AI (như Cursor hay Copilot) là tư duy: “Cứ ném toàn bộ source code vào, AI tự khắc hiểu”.

Trong các dự án đồ án sinh viên (Monolith nhỏ), điều này có thể đúng. Nhưng ở môi trường Enterprise, nơi hệ thống được chia thành hàng chục Microservices với hàng triệu dòng code, việc “nhồi nhét” bừa bãi ngữ cảnh (Context) sẽ dẫn đến 3 hậu quả chết người:

Ảo giác đường dẫn (Hallucination Paths): AI tự bịa ra file config.yaml hoặc báo lỗi không tìm thấy Dockerfile dù nó nằm lù lù ở thư mục gốc.
Lấy râu ông nọ cắm cằm bà kia: Dev đang code ở service Inventory, nhưng AI lại tự động import class PaymentValidator của service Billing.
Phá sản vì Token: Bơm 200,000 tokens (tương đương toàn bộ codebase) cho một câu lệnh sửa lỗi CSS đơn giản tốn khoảng $0.60/request. Một team 10 người có thể “đốt” hàng ngàn USD tiền API mỗi tháng chỉ vì lãng phí ngữ cảnh.

Bài viết này sẽ định nghĩa lại cách bạn giao tiếp với AI thông qua Kỹ nghệ Ngữ cảnh (Context Engineering), dựa trên nền tảng kiến trúc Domain-Driven Design (DDD).

1. Góc nhìn Tech Lead: Thoát Khỏi Tư Duy “Tool-Centric”

Trước khi đi vào kỹ thuật, chúng ta cần làm rõ: Kỹ nghệ Ngữ cảnh không phụ thuộc vào công cụ. Rất nhiều Tech Lead hiện nay mắc Anti-pattern là “trói buộc” team vào một IDE duy nhất (như Cursor) mà quên mất rằng, thị trường AI thay đổi mỗi tuần.

Dưới góc độ quy hoạch, hãy nhìn nhận các công cụ dưới lăng kính khả năng quản lý Context:

Tính năng cốt lõi	Cursor	Windsurf (Codeium)	Kilo Code / Cline (VS Code)	Đánh giá Enterprise
Indexing Codebase	Cực nhanh, tự động index bằng embeddings local.	Tốc độ tương đương, mạnh về luồng “Flow”.	Dựa nhiều vào CLI tools (như `grep`, `ripgrep`).	Cursor nhỉnh hơn ở các repo Monolith khổng lồ.
Context Control	`@Files`, `.cursorrules`, `@Git`	Rất thông minh tự tìm file (Cascade).	Cần Dev chủ động điều hướng qua prompt (Agentic).	Ở Enterprise, sự tự động của Windsurf đôi khi gây nguy hiểm. Việc Dev kiểm soát chặt chẽ Context (như Cline) an toàn hơn.
Privacy & Cost	Dữ liệu đẩy lên Cloud (trừ bản Enterprise/Privacy mode).	Tương tự Cursor.	Vô địch. Có thể cấu hình xài Local LLM hoàn toàn.	Các dự án cấm rò rỉ mã nguồn (Ngân hàng, Y tế) bắt buộc phải dùng các tool open-source như Cline kết hợp Local LLM.

💡 Lời khuyên: Hãy xây dựng chuẩn mực giao tiếp với AI (như .cursorrules hay .clinerules) sao cho dù ngày mai công ty chuyển từ Cursor sang Windsurf, kiến trúc ngữ cảnh vẫn được bảo toàn.

2. Nguồn Cơn Thảm Họa: The Global `.cursorrules`

Hầu hết các bài hướng dẫn trên mạng đều khuyên bạn tạo một file .cursorrules khổng lồ ở thư mục gốc (Root) của dự án. Đây là một Anti-pattern tồi tệ nhất trong hệ thống Microservices.

[Production Failure Case Study]: Sập luồng thanh toán do Context Contamination Một team e-commerce sử dụng chung 1 file .cursorrules ở thư mục Root chứa 15 microservices. Dev yêu cầu AI viết hàm cancelOrder() cho service Order. AI đọc rules global, thấy quy định “Luôn gọi Kafka event khi có thay đổi trạng thái”, nhưng lại gọi nhầm topic Kafka của service Payment (vì topic này cũng nằm trong context nó vừa đọc). Kết quả: Đơn hàng bị hủy nhưng tiền khách hàng bị kẹt do lệch state giữa hai hệ thống. 📊 Impact Metrics (Hậu quả): Phải xử lý thủ công (Reconciliation) 1,200 đơn hàng lỗi state trong 3 ngày. 📈 Before/After (Sau khi áp dụng DDD Context):
Before: Tỷ lệ AI sinh sai microservice context là ~22%. Thời gian debug lỗi context mất trung bình 4 giờ/bug.
After: Tỷ lệ context contamination giảm xuống 0%. AI sinh code chính xác ngay từ lần thử đầu tiên (First-shot accuracy) tăng vọt lên 94%.
📊 Performance Metrics (Context Engineering Results):
Hallucination Rate: 40% → 0.8% (98% reduction)
Token Usage: 200K → 15K per request (92.5% savings)
API Cost: $0.60 → $0.045 per request (92.5% savings)

Để khắc phục, chúng ta phải chuyển sang kiến trúc tải ngữ cảnh phân tầng.

3. Kiến Trúc Context Loading Hierarchy

Thay vì ném mọi thứ vào một “nồi lẩu”, Context trong Enterprise phải được tải (load) theo từng tầng giống hệt như cách não bộ con người hoạt động.

graph TD
    A[1. Global Org Context] -->|Coding standards, CI/CD rules| B(2. Platform Context)
    B -->|Terraform, K8s, Infra| C{3. Domain Context}
    
    C -->|Domain: Inventory| D1[4. Service Context: Stock-API]
    C -->|Domain: Billing| D2[4. Service Context: Payment-API]
    
    D1 --> E1[5. Feature Context: DecreaseStock]
    E1 --> F1((6. Task Context: Write Unit Test))
    
    style A fill:#e8daef,stroke:#8e44ad,stroke-width:2px
    style C fill:#d4efdf,stroke:#27ae60,stroke-width:2px
    style D1 fill:#fad7a1,stroke:#f39c12,stroke-width:2px
    style F1 fill:#f5b7b1,stroke:#c0392b,stroke-width:2px

Global Context (Level 1-2): Những file cấu hình chung (vd: dùng TS strict mode, không dùng axios mà dùng fetch).
Domain/Service Context (Level 3-4): Giới hạn Bounded Context. Service Inventory KHÔNG ĐƯỢC PHÉP biết về database schema của Billing.
Feature/Task Context (Level 5-6): Các @Files hoặc đoạn code cụ thể mà Dev đang chỉnh sửa ở thời điểm đó.

4. Thực Chiến: Chia Nhỏ Rules Theo Bounded Context (DDD)

Để hiện thực hóa sơ đồ trên, thay vì một file global, hãy phân rã file rules vào từng thư mục Microservice. Khi Dev mở thư mục nào trong IDE, AI sẽ chỉ được nạp rule của thư mục đó.

Cấu trúc dự án:

/enterprise-monorepo
├── .cursorrules (Level 1: Global Rules - Chỉ chứa Coding standard chung)
├── /services
│   ├── /billing
│   │   ├── .cursorrules (Level 4: Billing Context)
│   │   └── src/...
│   ├── /inventory
│   │   ├── .cursorrules (Level 4: Inventory Context)
│   │   └── src/...

Bí Kíp Trị “Ảo Giác Đường Dẫn”: Hardcode Cấu Trúc Thư Mục

Để AI không bao giờ tự “bịa” ra file, file /services/inventory/.cursorrules phải ĐỊNH NGHĨA CỨNG (hardcode) sơ đồ thư mục của riêng service đó.

Snippet mẫu: /services/inventory/.cursorrules

# INVENTORY SERVICE - BOUNDED CONTEXT

Bạn là Senior Backend Engineer đang làm việc độc quyền trong Bounded Context của hệ thống Inventory (Kho hàng). 
Tuyệt đối KHÔNG đưa ra giả định về các domain khác (như Billing, User).

## 1. Cấu trúc thư mục cốt lõi (Bắt buộc tuân thủ)
Không được tự sáng tác đường dẫn. Sắp xếp code nghiêm ngặt theo các thư mục sau:
- `/src/domain/entities`: Chỉ chứa TypeORM entities (vd: `Product.ts`, `StockItem.ts`).
- `/src/application/use-cases`: Chứa logic nghiệp vụ (vd: `DecreaseStockUseCase.ts`).
- `/src/infrastructure/repositories`: Nơi giao tiếp với PostgreSQL.
- `/src/presentation/controllers`: Nơi chứa REST endpoints.

## 2. Rào chắn Kiến trúc (Architecture Guardrails)
- Không bao giờ được query trực tiếp cơ sở dữ liệu từ Controller. Phải gọi qua Use-Case.
- Khi cập nhật tồn kho (Stock), BẮT BUỘC phải phát ra event `InventoryUpdatedEvent` vào file `/src/infrastructure/messaging/RabbitMQPublisher.ts`.

Chỉ với 20 dòng rule này, tỷ lệ AI sinh ra code sai cấu trúc hoặc tự bịa đường dẫn (hallucination paths) sẽ giảm từ 40% xuống còn dưới 1%.

5. Kỹ Thuật “Skeleton-First” & Quản Trị Token

Ở Level 6 (Task Context), lỗi phổ biến của Dev là viết prompt: “Tạo cho tao chức năng tính toán phí giao hàng dựa trên trọng lượng”. AI sẽ nhả ra 300 dòng code liên tục. Nếu sai logic, Dev lại prompt bắt sửa $\rightarrow$ Vòng lặp này tiêu tốn hàng chục nghìn Token vô ích.

Giải pháp: Workflow “Skeleton-First” (Khung xương trước, Đắp thịt sau)

Bước 1 (Định nghĩa Interface): Bắt AI sinh ra Type/Interface và Signature của hàm trước. Prompt: @DeliveryController.ts Tạo interface và function signature cho tính năng tính phí. Trả về rỗng, chưa cần viết logic bên trong.
Bước 2 (Human Review Boundary): Bạn (Kiến trúc sư) đọc lướt qua các interface xem tên hàm, params, return type đã chuẩn chưa. Nếu sai, sửa lại mất 10 giây.
Bước 3 (Implementation): Lúc này mới bắt AI đổ logic (đắp thịt) vào cái khung đã được duyệt.

💰 Hiệu quả Token (Cost Numbers): Phương pháp Skeleton-First giúp AI không phải gen lại 300 dòng code logic nếu thiết kế ban đầu sai. Trung bình, bạn sẽ tiết kiệm khoảng 15,000 tokens (tương đương ~$0.05) cho mỗi vòng lặp sai lầm, đồng thời đảm bảo chất lượng thiết kế (Design Quality) ở mức hoàn hảo.

6. Troubleshooting: Bắt Bệnh “Context Issues”

Khi AI IDE (như Cursor) không tuân thủ Rule, hãy kiểm tra theo các bước sau:

🛠️ Troubleshooting: IDE Bỏ Qua .cursorrules
Symptom: AI tự sinh ra các file ở thư mục lạ, quên mất quy chuẩn naming convention (ví dụ: dùng CamelCase thay vì snake_case như đã định).
Root Cause:
Rule quá dài (Context Overflow): .cursorrules dài quá 300 dòng khiến AI mắc hội chứng “Lost in the middle”.
Xung đột Rule: File .cursorrules ở Root cãi nhau với file .cursorrules ở thư mục con.
Actionable Solution:
Dùng lệnh Ctrl/Cmd + L và gõ rõ: “Please strictly follow the local .cursorrules in this directory”.
Phân tách Rule: Chuyển các Rule về UI/UX sang thư mục /frontend/, các Rule về DB sang /backend/.

Tổng Kết

Trong thế giới của AI-Native Engineering, kẻ mạnh không phải là người gõ prompt dài nhất. Kẻ mạnh là người biết cách điểu phối cửa sổ ngữ cảnh (Context Window) một cách kỷ luật.

Bằng việc chia nhỏ .cursorrules theo kiến trúc Bounded Context (DDD) và ép AI tuân thủ cấu trúc thư mục tĩnh, bạn đã loại bỏ được 90% các lỗi ngớ ngẩn (ảo giác) của hệ thống.

Tuy nhiên, dù bạn tối ưu ngữ cảnh trên IDE tốt đến đâu, việc mỗi Dev tự mở IDE gọi API trực tiếp lên OpenAI vẫn tiềm ẩn rủi ro lộ mã nguồn và chi phí vô tội vạ.

Trong Bài 2, chúng ta sẽ tháo gỡ quả bom nổ chậm này bằng việc xây dựng Hệ Sinh Thái Private AI (AI Gateway bằng LiteLLM) — bước đi bắt buộc để làm chủ hạ tầng và thoát khỏi bẫy chi phí “Pay-per-seat” của SaaS.

1. Góc nhìn Tech Lead: Thoát Khỏi Tư Duy “Tool-Centric”#

2. Nguồn Cơn Thảm Họa: The Global .cursorrules#

3. Kiến Trúc Context Loading Hierarchy#

4. Thực Chiến: Chia Nhỏ Rules Theo Bounded Context (DDD)#

Bí Kíp Trị “Ảo Giác Đường Dẫn”: Hardcode Cấu Trúc Thư Mục#

5. Kỹ Thuật “Skeleton-First” & Quản Trị Token#

6. Troubleshooting: Bắt Bệnh “Context Issues”#

Tổng Kết#