Kiến trúc là gì & Tính độc lập

01 Kiến trúc là gì — và ai làm nó

Có thể bạn nghĩ mục tiêu của kiến trúc là "làm hệ thống chạy đúng". Tất nhiên ta muốn nó chạy đúng — nhưng architecture rất ít chi phối behavior. Điều quan trọng nhất kiến trúc làm được cho hành vi là phơi bày ý đồ (intent) của hệ thống ra cấp độ cấu trúc, để lập trình viên nhìn là thấy.

Kiến trúc sư vẫn là lập trình viên

Đừng tin lời nói dối rằng kiến trúc sư "rút khỏi code để lo việc cấp cao". Họ không hề. Kiến trúc sư là những lập trình viên giỏi nhất và tiếp tục nhận task lập trình. Lý do: họ không thể làm tốt việc của mình nếu không tự nếm trải những vấn đề mà các quyết định kiến trúc của họ gây ra cho phần còn lại của đội.

02 Để mở các lựa chọn: Policy vs Detail

Phần mềm được phát minh để "soft"-ware — dễ đổi hành vi máy móc. Giữ cho nó mềm nghĩa là để mở càng nhiều lựa chọn càng tốt, càng lâu càng tốt (leaving options open), bằng cách trì hoãn các quyết định về những chi tiết không quan trọng.

Không cần chọn loại database sớm: policy cấp cao lẽ ra không quan tâm nó là relational, distributed, hierarchical hay flat file. Không cần chọn web server sớm: policy không nên biết mình đang được phân phối qua web. Lỡ công ty đã "chốt" một DB/framework rồi? Kiến trúc sư giỏi vờ như chưa chốt, và shape hệ thống sao cho quyết định ấy vẫn có thể đổi càng lâu càng tốt.

03 Bốn thứ một kiến trúc tốt phải hỗ trợ

Một kiến trúc tốt phải đồng thời nâng đỡ vòng đời hệ thống trên bốn mặt — và cân bằng tất cả bằng một cấu trúc component thỏa mãn lẫn nhau. Nghe thì dễ; làm mới khó.

04 Decoupling: tầng ngang vs use case dọc

Kiến trúc tốt khiến hệ thống dễ thay đổi theo mọi hướng nó phải đổi, bằng cách để mở các lựa chọn. Có hai trục tách rời, và một câu hỏi thứ ba về mức độ tách.

flowchart TB
  subgraph L["Tách NGANG · Decoupling Layers"]
    direction TB
    UI["UI"]:::core --> APP["App-specific rules"]:::mid --> DOM["App-independent rules"]:::mid --> DB["Database"]:::out
  end
  subgraph V["Tách DỌC · Decoupling Use Cases"]
    direction LR
    U1["addOrder
(lát cắt)"]:::slice
    U2["deleteOrder
(lát cắt)"]:::slice
    U3["viewReport
(lát cắt)"]:::slice
  end
  L --> V
  classDef core fill:#dce7f1,stroke:#2e5e8c,color:#14233b;
  classDef mid fill:#e2edf3,stroke:#2f6d93,color:#14233b;
  classDef out fill:#e2edf3,stroke:#2f6d93,color:#14233b;
  classDef slice fill:#dce7f1,stroke:#2e5e8c,color:#14233b;
            

Decoupling Modes — tách tới mức nào?

RAG · use case dọc & ranh giới service

RAG  Hai use case "ingest tài liệu" và "hỏi đáp" đổi vì lý do khác nhau → tách thành hai lát dọc riêng, mỗi lát có pipeline riêng:

# Lát dọc 1 · INGEST — đổi khi format tài liệu / chiến lược chunk đổi
class IngestUseCase:
    def run(self, doc) -> None:
        chunks = self.splitter.split(doc)        # UI/intake riêng
        self.vector_store.upsert(self.embed(chunks))

# Lát dọc 2 · ASK — đổi khi cách retrieve / prompt trả lời đổi
class AskUseCase:
    def run(self, question) -> str:              # độc lập với Ingest
        ctx = self.vector_store.search(question)
        return self.llm.generate(self.prompt(ctx, question))

RAG  Ranh giới PHP (web) ↔ Python (pipeline) đi qua network = service-level decoupling sẵn có. Nhưng đừng vì thế mà chẻ tiếp pipeline Python thành 5 micro-service "cho hiện đại":

// PHP CHỈ ở ranh giới — không nhúng logic pipeline
$res = Http::post('http://rag-svc/ask', ['q' => $question]);
return $res->json('answer');   // service-level: độc lập source & binary
// Bên trong rag-svc, Ingest & Ask vẫn chung 1 address space (source-level)
// → giữ option "tách thành service riêng" để mở, chưa tốn ngay.

05 Trùng lặp THẬT vs trùng lặp ngẫu nhiên

Kiến trúc sư hay sa vào một cái bẫy: sợ trùng lặp. Nhưng có hai loại trùng lặp rất khác nhau — và gộp nhầm loại thứ hai sẽ tạo coupling không đáng có.

RAG · cùng format prompt ≠ phải gộp

RAG  Use case "ingest" và "ask" tình cờ cùng dựng một prompt header trông giống nhau. Đừng vội rút ra hàm dùng chung — chúng sẽ tiến hóa khác hướng:

# Trông giống nhau HÔM NAY, nhưng đổi vì lý do khác nhau → KHÔNG gộp vội
def ingest_prompt(chunk):   # đổi khi tinh chỉnh cách mô tả tài liệu để embed
    return f"Tài liệu:\n{chunk}"

def ask_prompt(ctx, q):     # đổi khi tinh chỉnh giọng trả lời, chống hallucination
    return f"Ngữ cảnh:\n{ctx}\n\nCâu hỏi: {q}"
# Gộp lại = ép hai use case coupling; chỉ unify nếu CHẮC là true duplication.

06 Ghi nhớ nhanh