Component Coupling

01 Ba nguyên lý ghép nối component

Sau ba nguyên lý cohesion (lớp nào thuộc component nào), tới lượt ba nguyên lý coupling điều phối các mũi tên phụ thuộc giữa component. Khác với cohesion, ba nguyên lý này không thể thiết kế trước — chúng tiến hóa cùng hệ thống, là tấm bản đồ về tính dễ-build và dễ-bảo-trì.

02 ADP — Không cho phép chu trình

Bạn từng làm cả ngày, code chạy ngon, về nhà — sáng hôm sau quay lại thì hỏng hết? Vì có ai đó ở lại muộn hơn và sửa một component bạn đang phụ thuộc vào. Martin gọi đây là "the morning after syndrome" — và nó càng thảm khốc khi đội & dự án càng to.

Từ "weekly build" tới khủng hoảng tích hợp

Giải pháp cũ: cả tuần ai làm việc nấy, thứ Sáu mới tích hợp (weekly build). Nhưng khi dự án phình to, gánh nặng tích hợp tràn sang thứ Bảy, rồi lùi lên thứ Năm, rồi thành biweekly build… lịch build cứ phải kéo dài, làm tăng rủi ro và mất đi phản hồi nhanh.

Phát hiện & phá chu trình

Khi đồ thị xuất hiện chu trình (vd A → B → C → A), các component trong vòng thực chất dính thành một khối: phải build, test, release cùng nhau. Có hai cách phá vòng:

flowchart LR
  subgraph BAD["✗ Có chu trình"]
    direction LR
    e1["Entities"]:::core --> au1["Authorizer"]:::out
    au1 --> u1["User"]:::out
    u1 -. "vòng ngược" .-> e1
  end
  subgraph FIX["✓ Phá bằng DIP (chèn interface)"]
    direction LR
    e2["Entities"]:::core --> pi["«interface»
Permissions"]:::core
    au2["Authorizer"]:::out -. implements .-> pi
    u2["User"]:::out --> e2
  end
  BAD --> FIX
  classDef core fill:#14233b,stroke:#0b1626,color:#f4efe3;
  classDef out fill:#e2edf3,stroke:#2f6d93,color:#1c1a14;
            

03 SDP — Phụ thuộc theo hướng ổn định

"Ổn định" không phải tần suất thay đổi — mà là lượng công sức cần để tạo ra một thay đổi. Dựng đồng xu trên cạnh: nó không đổi nhưng chẳng ổn định, vì chỉ cần khẽ chạm là đổ. Một cái bàn thì ổn định vì rất khó lật.

Trong phần mềm: một component bị nhiều component khác phụ thuộc vào sẽ rất ổn định — nó có nhiều lý do để không đổi (đổi là phải hoà giải với tất cả những kẻ phụ thuộc). Trớ trêu thay, một module bạn thiết kế để dễ đổi có thể bị người khác "treo" một dependency lên và bỗng trở nên khó đổi.

Đo Instability: I = Fan-out / (Fan-in + Fan-out)

04 SAP — Ổn định thì phải trừu tượng

High-level policy (chính sách nghiệp vụ, quyết định kiến trúc) không nên hay đổi → phải đặt vào component ổn định (I = 0). Nhưng nếu code chính sách nằm trong component cứng như đá thì làm sao mở rộng? Câu trả lời là OCP: dùng abstract class và interface để mở rộng được mà không cần sửa.

SAP nói: hai vị trí dưới đây đều ĐÚNG — chúng là hai đầu lành mạnh của "chuỗi chính". Vùng cấm là khi lệch khỏi cả hai (xem Main Sequence ở mục sau).

Đo Abstractness: A = Na / Nc

05 Main Sequence & khoảng cách D

Vẽ A (trục tung) theo I (trục hoành), ta thấy hai vị trí "tốt": ổn định-trừu-tượng ở góc trên-trái (0, 1) và bất-ổn-cụ-thể ở góc dưới-phải (1, 0). Hai góc còn lại là vùng cấm (zones of exclusion).

Distance: D = |A + I − 1|

Khoảng cách từ component tới Main Sequence: D = |A + I − 1|, phạm vi [0, 1]. D ≈ 0 nghĩa là nằm ngay trên đường lý tưởng; D gần 1 nghĩa là cần xem xét & tái cấu trúc. Có thể tính mean/variance của D toàn hệ thống, đặt "control limit" để soi các component bất thường.

06 Ghi nhớ nhanh

RAG Soi qua hệ "Hỏi–đáp tài liệu"

Áp ba nguyên lý lên hệ RAG: Python (FastAPI) lo pipeline (chunk→embed→retrieve→generate); PHP (Laravel) chỉ ở ranh giới service. Ta tách thành các component: rag-core (chính sách, abstraction), ingestion, retriever, store, api.

SDP — rag-core ổn định, mọi thứ trỏ về nó

RAG  rag-core chỉ chứa Protocol (interface) → Fan-out ≈ 0 → I ≈ 0. ingestion và api phụ thuộc vào nó, không bao giờ ngược lại — I giảm dần theo hướng phụ thuộc.

# rag-core/ports.py  — ỔN ĐỊNH: chỉ abstraction, không Fan-out
class Retriever(Protocol):
    def search(self, query: str, k: int) -> list[Chunk]: ...

# ingestion/pipeline.py  — BẤT ỔN: phụ thuộc XUỐNG rag-core
from rag_core.ports import Retriever          # mũi tên trỏ về phía ổn định ✓
def index(docs, retriever: Retriever): ...    # rag-core KHÔNG biết tới ingestion

ADP — phá chu trình retriever ⇄ store

RAG  retriever gọi store để lấy vector, nhưng store lại gọi retriever để rerank → chu trình. Chèn interface vào rag-core để đảo chiều (DIP):

# rag-core/ports.py  — interface chung, cả hai cùng phụ thuộc xuống
class Reranker(Protocol):
    def rerank(self, chunks: list[Chunk]) -> list[Chunk]: ...

# store/vector_store.py  — KHÔNG còn import retriever; nhận Reranker qua tham số
def query(self, vec, reranker: Reranker):     # vòng ngược bị phá ✓
    return reranker.rerank(self._knn(vec))    # đồ thị trở lại DAG

SAP — rag-core ổn định nên chỉ chứa abstraction

RAG  Vì rag-core ổn định nhất (I≈0), nó phải trừu tượng nhất (A≈1) — toàn Protocol, không logic cụ thể. PHP ở ranh giới chỉ gọi service qua HTTP, không chạm vào abstraction này.

// app/Services/RagGateway.php — component bất ổn: cụ thể, dễ đổi
class RagGateway {
    public function ask(string $q): array {
        // chỉ gọi HTTP sang FastAPI; không phụ thuộc rag-core
        return Http::post(config('rag.url').'/answer', ['q' => $q])->json();
    }
}