Layers, Services, Test & Embedded

01 Layers & Boundaries — ranh giới là quyết định chi phí

Ta dễ hình dung mọi hệ thống chỉ gồm ba thành phần: UI · business rules · database. Với vài hệ thống đơn giản, thế là đủ. Nhưng với hầu hết hệ thống, số ranh giới thực sự lớn hơn nhiều — và Martin dùng game Hunt the Wumpus (1972) để phơi bày điều đó.

flowchart TB
  EN["English"]:::out --> LANG
  ES["Spanish"]:::out --> LANG
  LANG["Language API"]:::mid
  CON["Console"]:::out --> TXT
  SMS["SMS · Chat"]:::out --> TXT
  TXT["Text Delivery API"]:::mid
  LANG --> GR
  TXT --> GR
  GR["Game Rules"]:::core
  GR --> MOVE["Move Management
(bản đồ, hang động)"]:::mid
  GR --> PLAYER["Player Management
(máu, thắng/thua)"]:::core
  GR --> STORE["Data Storage API"]:::mid
  STORE --> FLASH["Flash · Cloud · RAM"]:::out
  classDef core fill:#dce7f1,stroke:#2e5e8c,color:#14233b;
  classDef mid fill:#e2edf3,stroke:#2f6d93,color:#14233b;
  classDef out fill:#eef4f1,stroke:#8c8675,color:#14233b;
            

Architecture là về CHI PHÍ

Vạch một ranh giới kiến trúc — khi triển khai đầy đủ — là việc tốn kém (expensive). Nhưng bỏ qua nó cũng tốn kém: thêm vào sau này tốn gấp bội, ngay cả khi đã có test-suite đầy đủ và kỷ luật refactoring. Kiến trúc sư mắc kẹt giữa hai bờ vực:

02 Service KHÔNG tự động là kiến trúc

Dùng service / micro-service không tự sinh ra kiến trúc tốt. Kiến trúc được định nghĩa bởi ranh giới tách high-level policy khỏi low-level detail và tuân Dependency Rule. Service chỉ "chia tách hành vi" mà không có ranh giới rõ ràng thì chẳng khác gì những lời gọi hàm đắt đỏ qua mạng (expensive function calls).

The Kitty Problem — cross-cutting concern

Hệ thống điều phối taxi gồm nhiều service: UI · Finder · Selector · Dispatcher. Nay thêm tính năng "giao mèo con" (Kitty): tài xế dị ứng mèo không được chọn; xe vừa chở mèo trong 3 ngày không phục vụ khách dị ứng. Bao nhiêu service phải đổi? Tất cả. Đây là bản chất của cross-cutting concern: functional decomposition rất dễ vỡ trước tính năng mới cắt ngang mọi hành vi.

flowchart TB
  subgraph BAD["✗ Chỉ chia theo chức năng — Kitty cắt ngang TẤT CẢ"]
    direction LR
    UI1["UI"]:::bad --> FIN1["Finder"]:::bad --> SEL1["Selector"]:::bad --> DIS1["Dispatcher"]:::bad
  end
  subgraph GOOD["✓ Mỗi service có component bên trong theo Dependency Rule"]
    direction TB
    BASE["Abstract base classes
(logic chung)"]:::core
    RIDES["Rides component"]:::mid
    KITS["Kittens component
(thêm = jar/dll mới)"]:::mid
    RIDES -.->|override| BASE
    KITS -.->|override| BASE
  end
  BAD --> GOOD
  classDef bad fill:#f4dcd5,stroke:#b23a2e,color:#14233b;
  classDef core fill:#dce7f1,stroke:#2e5e8c,color:#14233b;
  classDef mid fill:#e2edf3,stroke:#2f6d93,color:#14233b;
            

RAG · decoupling fallacy qua schema embedding

RAG  Tách ingestion và query thành hai service trông như đã decouple. Nhưng cả hai vẫn coupling chặt qua một cross-cutting concern: schema/chiều của vector embedding. Đổi model embedding = field thay đổi = phải sửa cả hai, đồng bộ tuyệt đối:

# Service A · ingestion — ghi vector theo schema (model X, dim 1536)
def ingest(doc):
    vec = embed(doc, model="text-embedding-3-small")  # dim=1536
    store.upsert(id=doc.id, vector=vec)               # field "vector"

# Service B · query — đọc vector CÙNG schema để search
def query(q):
    qv = embed(q, model="text-embedding-3-small")     # PHẢI khớp dim=1536
    return store.search(qv, top_k=5)
# Đổi sang model dim=3072 ⟹ sửa CẢ HAI service + re-index toàn bộ.
# Chạy khác process ≠ decoupled: chúng coupling qua schema embedding.

03 The Test Boundary — test ở vòng ngoài cùng

Sự thật bất ngờ: test là một phần của hệ thống và tham gia vào kiến trúc như mọi component khác. Về mặt kiến trúc, mọi loại test đều tương đương (unit, integration, acceptance, TDD, Cucumber…). Test tuân Dependency Rule — rất cụ thể, chi tiết, luôn phụ thuộc hướng vào trong.

The Fragile Tests Problem

Khi test coupling chặt với cấu trúc hệ thống, chúng phải đổi cùng hệ thống. Một thay đổi nhỏ ở component chung có thể làm hàng trăm, hàng nghìn test vỡ. Hệ quả ngược đời: test mong manh khiến hệ thống cứng nhắc — dev sợ thay đổi vì biết một sửa đổi nhỏ sẽ phá 1000 test (hãy tưởng tượng cuộc nói chuyện với team marketing xin đổi navigation).

Giải pháp: Testing API

Tạo một Testing API chuyên dụng mà test dùng để xác minh business rules. Mục đích: decouple cấu trúc của test khỏi cấu trúc của ứng dụng — không chỉ tách test khỏi UI. API này ẩn cấu trúc ứng dụng khỏi test, để hai bên tiến hóa độc lập: production code ngày càng trừu tượng & tổng quát, còn test ngày càng cụ thể & chi tiết.

RAG · Testing API tách test khỏi FAISS/OpenAI thật

RAG  Nếu test pipeline gọi thẳng FAISS index và OpenAI thật, chúng coupling cấu trúc với chi tiết hạ tầng volatile — đổi vendor/index là test vỡ hàng loạt. Dựng một Testing API cho phép xác minh business rule "retrieve đúng chunk" mà không chạm chi tiết thật:

# Testing API · "siêu năng lực" để dựng trạng thái + kiểm tra rule,
# KHÔNG đụng FAISS/OpenAI thật → test khỏi structural coupling.
class RagTestHarness:
    def given_documents(self, *docs): ...      # nạp vào fake vector store
    def ask(self, q) -> Answer: ...            # chạy use case qua cổng
    def assert_cited(self, ans, doc_id): ...   # xác minh business rule

# Test chỉ nói NGÔN NGỮ NGHIỆP VỤ, không biết FAISS hay OpenAI:
def test_answer_cites_source(rag: RagTestHarness):
    rag.given_documents(doc("HAL ẩn chi tiết GPIO", id="d1"))
    ans = rag.ask("HAL làm gì?")
    rag.assert_cited(ans, "d1")     # đổi vector backend → test KHÔNG vỡ

04 Clean Embedded — đừng để software thành firmware

James Grenning mở chương bằng một câu của Doug Schmidt: "Phần mềm không hao mòn, nhưng firmware và hardware thì lỗi thời, buộc phải sửa software." Khoảnh khắc sáng tỏ: software có thể sống lâu, còn firmware sẽ lỗi thời khi hardware tiến hóa.

The Target-Hardware Bottleneck

Vấn đề đặc thù của nhúng: khi code không theo nguyên lý clean, bạn chỉ test được trên target hardware thật. Mà hardware thường được phát triển song song với software — có thể chưa có chỗ để chạy code; khi có thì hardware lại dính lỗi của chính nó, làm tiến độ chậm thêm. Đó là target-hardware bottleneck.

flowchart TB
  APP["Software
(business rules, sống lâu)"]:::core
  APP --> HAL["HAL · Hardware Abstraction Layer
Indicate_LowBattery() · store(name,value)"]:::mid
  APP --> OSAL["OSAL · OS Abstraction Layer
message passing, test points"]:::mid
  HAL --> FW["Firmware / BSP
Led_TurnOn(5) · GPIO · flash"]:::out
  OSAL --> OS["RTOS · Embedded Linux"]:::out
  FW --> HW["Hardware"]:::hw
  TEST["Off-target tests
(thay HAL/OSAL bằng fake)"]:::test -.->|substitution points| HAL
  TEST -.-> OSAL
  classDef core fill:#dce7f1,stroke:#2e5e8c,color:#14233b;
  classDef mid fill:#e2edf3,stroke:#2f6d93,color:#14233b;
  classDef out fill:#eef4f1,stroke:#8c8675,color:#14233b;
  classDef hw fill:#f4dcd5,stroke:#b23a2e,color:#14233b;
  classDef test fill:#dbeee8,stroke:#0f7d72,color:#14233b;
            

RAG · "HAL cho LLM/Vector" để test off-vendor

RAG  Vendor LLM/Vector đóng vai "hardware": dễ lỗi thời, đắt, không có khi test. Đặt một lớp trừu tượng kiểu HAL — app gọi nhu cầu nghiệp vụ, không gọi thẳng SDK vendor — để test off-"hardware" bằng implementation thay thế:

# "HAL" — API thiết kế theo nhu cầu software, ẩn chi tiết vendor
class LlmGate(Protocol):
    def answer(self, prompt: str) -> str: ...   # ~ Indicate_LowBattery()
class VectorGate(Protocol):
    def search(self, q: str, k: int) -> list[Chunk]: ...

# Off-"hardware": thay vendor thật bằng fake để test, không cần OpenAI/FAISS
class FakeLlm(LlmGate):
    def answer(self, prompt): return "stub answer"   # substitution point

def make_rag(llm: LlmGate, vec: VectorGate):   # app phụ thuộc INTERFACE
    ...   # đổi OpenAI→Anthropic, FAISS→pgvector = thay impl, app không đổi

05 Ghi nhớ nhanh