Ranh giới

01 Vạch lằn ranh ở đâu — và khi nào

Bạn vạch lằn ranh giữa thứ quan trọng và thứ không quan trọng. GUI không quan trọng với business rules → có một lằn ranh. Database không quan trọng với business rules → có một lằn ranh. Vẽ sớm để trì hoãn quyết định càng lâu càng tốt và không để chúng làm ô nhiễm core business logic.

Hướng phụ thuộc luôn trỏ về business rules

Đặt database sau một interface: BusinessRules dùng DatabaseInterface để load/save; DatabaseAccess hiện thực interface đó và điều khiển Database thật. Lằn ranh cắt ngang quan hệ kế thừa, ngay dưới interface — và mọi mũi tên phụ thuộc trỏ về phía business.

flowchart RL
  subgraph BIZ["Component · BusinessRules  (policy — quan trọng)"]
    BR["BusinessRules"]:::core
    DI["«interface»
DatabaseInterface"]:::core
    BR --> DI
  end
  subgraph DBC["Component · Database  (detail / plugin)"]
    DA["DatabaseAccess"]:::out
    DB[("Database
Oracle · MySQL · file")]:::out
    DA --> DB
  end
  DA -. "implements" .-> DI
  DBC ==>|"phụ thuộc trỏ về business"| BIZ
  classDef core fill:#dce7f1,stroke:#2e5e8c,color:#14233b;
  classDef out fill:#e2edf3,stroke:#2f6d93,color:#14233b;
            

02 Database & GUI chỉ là detail — Plugin architecture

Khách hàng & lập trình viên hay lẫn lộn "hệ thống là gì": họ thấy GUI và tưởng GUI chính là hệ thống. Họ quên một nguyên lý cốt yếu: IO is irrelevant. Đằng sau giao diện luôn có một model — tập data structure & hàm — và model ấy không cần giao diện để vận hành.

RAG · VectorStore & LLM là plugin

RAG  FAISS, OpenAI là detail. Để RAG core phụ thuộc vào interface chứ không vào FAISS/OpenAI cụ thể; phụ thuộc cài đặt trỏ ngược về core:

# --- RAG core (policy) — KHÔNG import faiss, không import openai ---
class VectorStore(Protocol):
    def search(self, q: str, k: int) -> list[str]: ...
class LLM(Protocol):
    def generate(self, prompt: str) -> str: ...

class AskUseCase:                       # core chỉ biết interface
    def __init__(self, store: VectorStore, llm: LLM): ...

# --- plugin (detail) — phụ thuộc TRỎ VỀ core ---
class FaissStore(VectorStore): ...      # cắm vào, rút ra tùy ý
class OpenAILLM(LLM): ...               # đổi sang Llama = thay 1 plugin

03 Giải phẫu băng ranh giới — chi phí tăng dần

Tại runtime, băng qua ranh giới (boundary crossing) chỉ là một hàm bên này gọi hàm bên kia và truyền kèm dữ liệu. Bí quyết là quản lý source code dependencies để dựng firewall chống thay đổi. Có nhiều "độ chắc vật lý" của ranh giới — chi phí giao tiếp càng cao thì cô lập càng mạnh:

flowchart LR
  M["Monolith
function call"]:::core --> D["Deployment
jar / DLL"]:::mid --> P["Local process
socket / IPC"]:::mid --> S["Service
network"]:::out
  classDef core fill:#dce7f1,stroke:#2e5e8c,color:#14233b;
  classDef mid fill:#e2edf3,stroke:#2f6d93,color:#14233b;
  classDef out fill:#e2edf3,stroke:#2f6d93,color:#14233b;
            

RAG · ranh giới service PHP ↔ Python

RAG  PHP (web) gọi pipeline Python qua HTTP = service-level boundary: chi phí cao (network, latency) nhưng cô lập chắc nhất, độc lập cả source lẫn binary. Vì đắt nên tránh chatty — gộp một request thay vì gọi qua lại nhiều lần:

// PHP CHỈ ở ranh giới network — không nhúng logic pipeline
// Một lần băng ranh giới gói trọn ngữ cảnh (tránh latency dồn)
$res = Http::timeout(30)->post('http://rag-svc/ask', [
    'q' => $question, 'top_k' => 5, 'lang' => 'vi',
]);
return $res->json('answer');   // service-level: chậm nhất, chắc nhất
// Bên trong rag-svc, các use case vẫn chung 1 address space (source-level).

04 Ranh giới một phần — rẻ hơn full boundary

Một full-fledged boundary rất đắt: cần reciprocal polymorphic interfaces (hai chiều), Input/Output data structures, và quản lý phụ thuộc để tách hai phía thành component compile & deploy độc lập. Tốn công dựng và tốn công bảo trì. Khi thấy quá đắt nhưng vẫn muốn chừa chỗ, kiến trúc sư dùng partial boundary làm placeholder. Ba kiểu:

RAG · reranker chưa tách hẳn = one-dimensional

RAG  Chưa chắc cần tách reranker thành service riêng, nhưng muốn chừa chỗ. Dựng một-chiều (Strategy): chỉ một interface, dependency inversion sẵn — chưa tốn full boundary:

# Strategy: 1 interface, dependency inversion sẵn — placeholder cho full boundary
class Reranker(Protocol):                       # ServiceBoundary
    def rerank(self, q: str, docs: list[str]) -> list[str]: ...

class NoopReranker(Reranker):                   # ServiceImpl mặc định
    def rerank(self, q, docs): return docs

# Core dùng interface, chưa tách thành component/deploy riêng (skip last step).
# Khi friction xuất hiện ⟶ nâng lên full boundary; chưa thì giữ rẻ.

05 YAGNI vs chừa chỗ — quyết ở điểm uốn

Cộng đồng Agile hay phản đối việc dựng sẵn ranh giới: vi phạm YAGNI ("You Aren't Going to Need It"). Nhưng kiến trúc sư đôi khi nhìn vấn đề và nghĩ: "Ừ, nhưng có thể tôi sẽ cần." Đó là lúc cân nhắc một partial boundary.

Phía bên kia là cái bẫy "skip the last step" của FitNesse: vì ranh giới giữa web component & wiki chẳng bao giờ thành hiện thực, nó dần yếu đi, phụ thuộc xuyên sai hướng, và nay tách lại là một cực hình. Bài học: partial boundary là lời hứa cần kỷ luật giữ — hoặc nâng lên full đúng lúc, hoặc nó sẽ tan.

06 Ghi nhớ nhanh