Chi tiết: DB · Web · Framework · Tổ chức

01 Tất cả đều là chi tiết

Cả Phần V của cuốn sách lặp đi lặp lại một thông điệp: những thứ developer hay coi là "trung tâm" — cơ sở dữ liệu, giao diện web, framework — thực ra chỉ là cơ chế (mechanisms) ở vòng ngoài cùng. Lõi nghiệp vụ (business rules) phải không hề biết chúng tồn tại. Quan hệ của database với kiến trúc, theo Martin, "giống như nắm cửa với kiến trúc của ngôi nhà".

flowchart LR
  subgraph OUT["Frameworks & Drivers — nơi mọi chi tiết trú ngụ"]
    DB["Database
(detail)"]:::det
    WEB["Web / GUI
(detail)"]:::det
    FW["Framework
(detail)"]:::det
  end
  OUT -->|"phụ thuộc trỏ VÀO TRONG"| CORE["Business Rules
Use Cases · Entities"]:::core
  classDef det fill:#f1dbe0,stroke:#9c3450,color:#14233b;
  classDef core fill:#14233b,stroke:#14233b,color:#f3ece0;
            

Vì sao tách bạch như vậy lại đáng giá? Vì nó cho phép bạn viết và kiểm thử business rules trước khi quyết định dùng Oracle, MySQL hay file phẳng — trước khi biết app sẽ chạy trên web, console hay thick client. Trong một dự án thật, Martin kể đội của ông không chạy database suốt 18 tháng đầu: không lo schema, không lo connection, và test chạy rất nhanh.

02 Database là một chi tiết

Cần phân biệt rạch ròi hai thứ thường bị gộp làm một:

Relational cũng chỉ là một công cụ lưu trữ

Mô hình quan hệ (relational model) tuy thanh lịch và mạnh mẽ, vẫn chỉ là một storage technology. Một ứng dụng tốt không nên biết hay quan tâm dữ liệu được tổ chức dưới dạng bảng (tables) hay không — kiến thức về cấu trúc bảng chỉ nên nằm ở các hàm tiện ích cấp thấp nhất, vòng ngoài cùng.

Vậy còn performance?

Phải, performance là một mối quan tâm kiến trúc. Nhưng với lưu trữ, nó vẫn chỉ là chi tiết cấp thấp. Đĩa quay chậm (độ trễ mili-giây) là lý do RDBMS ra đời với index, cache, query tối ưu — nhưng kiến trúc nên giả định đĩa không tồn tại và dữ liệu luôn sẵn trong RAM. Hiệu năng không biện minh cho việc cho database rò rỉ vào business rules.

Giai thoại của Martin: có lúc RDBMS bị nhét vào hệ thống vì lý do marketing (khách hàng kỳ vọng phải có một cái "checkbox" database), chứ không vì nhu cầu kỹ thuật. Giải pháp đúng: "bắt vít" nó bên cạnh hệ thống qua một kênh truy cập hẹp & an toàn, giữ lõi sạch.

03 Web là một chi tiết

Web "thay đổi mọi thứ" trong thập niên 1990? Martin nói: không, hoặc lẽ ra không nên. Web chỉ là dao động mới nhất trong một con lắc đã đu đưa từ thập niên 1960 — giữa dồn sức tính toán về central server và đẩy ra terminal.

Web chỉ là một delivery mechanism. Quyết định "app chạy trên web" nên được trì hoãn; kiến trúc phải càng vô tư càng tốt về việc nó được giao thế nào — để bạn có thể đổi sang console app, thick client hay web service mà không xáo trộn nền tảng. Cách làm: trừu tượng hóa ranh giới giữa UI và app thành các use case nhận input data trả output data qua data structure — vận hành UI như một IO device độc lập thiết bị.

04 Framework: hôn nhân bất đối xứng

Tác giả framework giải vấn đề của họ, không phải của bạn — chỉ là vấn đề thường chồng lấn đủ để framework hữu ích. Nhưng quan hệ giữa bạn và họ cực kỳ bất đối xứng (asymmetric).

Tài liệu của framework thường khuyên bạn quấn kiến trúc của mình quanh nó: kế thừa base class của framework, import tiện ích của nó vào tận business object, ghép càng chặt càng tốt. Với tác giả, ghép chặt là không rủi ro — họ kiểm soát framework; và một khi bạn đã "đeo nhẫn cưới", rất khó dứt ra.

05 Tổ chức code: 4 cách & "Chương còn thiếu"

Trong The Missing Chapter, Simon Brown nhắc: mọi lời khuyên thiết kế đẹp đến đâu cũng có thể đổ vỡ ở phút chót — vì "the devil is in the implementation details". Lấy use case "xem trạng thái đơn hàng" của một book store, có 4 cách tổ chức code:

Organization vs Encapsulation — cạm bẫy public

Đây mới là điểm chí mạng. Developer hay dùng public theo quán tính cơ bắp. Nếu mọi type đều public, các package chỉ còn là cơ chế tổ chức (như thư mục) chứ không còn đóng gói (encapsulation) — vì type public gọi được từ bất cứ đâu.

Case study Video Sales — lý thuyết thành hình

Chương 33 dựng một site bán video (kiểu cleancoders.com) để minh họa tất cả. Bắt đầu bằng nhận diện actors & use cases theo Single Responsibility Principle:

Hai chiều tách biệt trong sơ đồ: (1) tách actor theo SRP, (2) tách tầng policy theo Dependency Rule — cùng mục tiêu: cô lập những thứ đổi vì lý do khác nhau, ở nhịp khác nhau. Các component có thể đóng gói thành các .jar/.dll độc lập, rồi gộp lại linh hoạt khi cần (independent deployability).

Soi qua lăng kính RAG

RAG  Vector store là một detail. Core pipeline không nên biết nó nói chuyện với FAISS, pgvector hay Pinecone — chỉ biết một interface lưu/tìm vector. Đổi store = đổi 1 adapter, business rule bất động:

# core/ports.py — lõi chỉ biết cổng, không biết DB nào
class VectorStore(Protocol):
    def search(self, vec: list[float], k: int) -> list[Chunk]: ...

# core/retrieve.py — business rule, KHÔNG import faiss/pgvector
def retrieve(q: str, store: VectorStore, embed) -> list[Chunk]:
    return store.search(embed(q), k=5)        # đổi store = đổi adapter ngoài

# adapters/faiss_store.py — detail ở vòng ngoài cùng
class FaissStore:                              # implements VectorStore
    def search(self, vec, k): ...              # pgvector/Pinecone = adapter khác

RAG  Framework là detail — giữ ở ranh giới service. Business rule không được import FastAPI hay Laravel; framework chỉ là lớp giao tiếp mỏng ở "Main", gọi vào lõi sạch:

# main.py (vòng ngoài "bẩn") — framework chỉ ở đây
app = FastAPI()

@app.post("/ask")                              # @decorator không lọt vào core
def ask(req: AskRequest, svc: RagService = Depends(build)):
    return {"answer": svc.answer(req.q)}       # gọi vào lõi, lõi vô tư về FastAPI

RAG  Package by component cho rag-core. Ở ranh giới HTTP, web Laravel chỉ gọi service Python qua một cổng hẹp — đúng tinh thần "bắt vít detail bên cạnh", giữ component lõi sau một interface sạch:

// app/Services/RagClient.php — adapter mỏng sang component rag-core
class RagClient {
    public function ask(string $q): array {
        // web KHÔNG biết FAISS, embedding model hay prompt bên trong
        return Http::post(config('rag.url').'/ask', ['q' => $q])->json();
    }
}
// Controller chỉ chạm RagClient — không "đi tắt" vào lõi retrieve

06 Ghi nhớ nhanh & hoàn thành