Tài liệu chuyên sâu dành cho Backend Engineer, Golang/Node.js Developer, Tech Lead và Solution Architect. Viết bởi góc nhìn của một Principal Software Architect: pattern không phải là mục tiêu — pattern là kết quả của việc giải quyết một vấn đề thiết kế cụ thể.
Triết lý của bộ tài liệu này
Hầu hết tài liệu về Design Pattern bắt đầu bằng: “Singleton là… Factory là… Observer là…” — cách học này tạo ra những kỹ sư thuộc lòng 23 pattern nhưng không biết khi nào dùng, và tệ hơn, dùng pattern ở nơi không cần thiết (over-engineering).
Tài liệu này đi theo lộ trình ngược lại:
Business Problem
↓
Code bắt đầu đơn giản
↓
Yêu cầu thay đổi
↓
Code Smell xuất hiện
↓
Maintenance Cost tăng
↓
Refactoring từng bước
↓
Design Principle
↓
Design Pattern (xuất hiện một cách TỰ NHIÊN)
↓
Production
↓
Trade-offMỗi chương đều trả lời 5 câu hỏi:
- Kỹ thuật này giải quyết vấn đề gì?
- Nếu không dùng thì chuyện gì xảy ra?
- Có cách đơn giản hơn không?
- Nó có còn phù hợp với Golang hiện đại không?
- Khi nào nó trở thành anti-pattern?
Ví dụ minh họa dùng Golang làm chính, so sánh với TypeScript (Node.js) khi sự khác biệt ngôn ngữ làm thay đổi cách áp dụng.
Mục lục
✅ Level 1 — Software Design Fundamentals
| Chương | Chủ đề | Trạng thái |
|---|---|---|
| 1.1 | Vì sao code trở nên khó bảo trì — bản chất của Software Design | ✅ |
| 1.2 | Abstraction & Encapsulation — che giấu đúng thứ cần che | ✅ |
| 1.3 | Coupling, Cohesion & Dependency — thước đo của mọi quyết định thiết kế | ✅ |
| 1.4 | Composition vs Inheritance & Polymorphism | ✅ |
| 1.5 | Interface & Immutability — hai vũ khí của Go | ✅ |
✅ Level 2 — Design Principles
| Chương | Chủ đề | Trạng thái |
|---|---|---|
| 2.0 | SOLID — lịch sử ra đời và vấn đề nó giải quyết | ✅ |
| 2.1 | Single Responsibility Principle — trục của sự thay đổi | ✅ |
| 2.2 | Open/Closed Principle — mở rộng mà không sửa | ✅ |
| 2.3 | Liskov Substitution Principle — hợp đồng hành vi | ✅ |
| 2.4 | Interface Segregation Principle — interface nhỏ, phía consumer | ✅ |
| 2.5 | Dependency Inversion Principle — đảo chiều phụ thuộc | ✅ |
| 2.6 | DRY, KISS, YAGNI, Law of Demeter, Tell Don’t Ask | ✅ |
✅ Level 3 — Refactoring
| Chương | Chủ đề | Trạng thái |
|---|---|---|
| 3.0 | Technical Debt & Legacy Code — kinh tế học của việc refactor | ✅ |
| 3.1 | Code Smells “phình to”: Long Method, Large Class, God Object, Primitive Obsession, Data Clumps | ✅ |
| 3.2 | Code Smells coupling: Duplicate Code, Shotgun Surgery, Feature Envy, Message Chains, Middle Man | ✅ |
| 3.3 | Kỹ thuật cơ bản: Extract Method, Move Method, Extract Class, Introduce Parameter Object | ✅ |
| 3.4 | Kỹ thuật cấu trúc: Replace Conditional with Polymorphism, Replace Inheritance with Composition, Replace Loop with Strategy | ✅ |
✅ Level 4 — Design Patterns
| Chương | Chủ đề | Trạng thái |
|---|---|---|
| 4.0 | Design Patterns — cách đọc GoF bằng con mắt 2026 | ✅ |
| 4.1 | Factory Method & Abstract Factory | ✅ |
| 4.2 | Builder & Functional Options (kèm so sánh Factory vs Builder) | ✅ |
| 4.3 | Singleton & Prototype | ✅ |
| 4.4 | Adapter & Facade (kèm so sánh) | ✅ |
| 4.5 | Decorator & Proxy — và Middleware (kèm bảng so sánh 4 pattern “bọc”) | ✅ |
| 4.6 | Composite, Bridge & Flyweight | ✅ |
| 4.7 | Strategy & State (kèm so sánh Strategy vs State, Interface vs Generics) | ✅ |
| 4.8 | Observer & pub/sub | ✅ |
| 4.9 | Command, Chain of Responsibility & Mediator | ✅ |
| 4.10 | Template Method, Visitor, Iterator & Memento | ✅ |
| 4.11 | Dependency Injection & DI Container (kèm so sánh DI vs Service Locator) | ✅ |
| 4.12 | Repository, Unit of Work & Specification | ✅ |
| 4.13 | Pipeline, Plugin, Domain Events, Saga & Outbox — bản đồ GoF/Enterprise/Go idiom | ✅ |
✅ Level 5 — Production Architecture
| Chương | Chủ đề | Trạng thái |
|---|---|---|
| 5.0 | Domain-Driven Design — strategic (bounded context, ubiquitous language, ACL) & tactical (aggregate, value object) | ✅ |
| 5.1 | Clean & Hexagonal Architecture — một ý tưởng, nhiều tên gọi; bản đồ package Go thực dụng | ✅ |
| 5.2 | Event-driven Architecture & CQRS (+ Event Sourcing) — bảng quyết định kiến trúc tổng | ✅ |
| 5.3 | Production Case Studies: io/net/http/context, Gin/Echo, Uber Fx, GORM/Ent/sqlc, Redis/Kafka client, Kubernetes, Docker, Terraform | ✅ |
| 5.4 | Tổng kết toàn bộ tài liệu — sáu câu hỏi cho mọi design review, lộ trình đọc tiếp | ✅ |
Cách đọc tài liệu
Nếu bạn là Senior Engineer muốn hệ thống hóa lại kiến thức: đọc tuần tự từ Level 1. Những chương đầu có thể quen thuộc, nhưng góc nhìn “chi phí thay đổi” và các trade-off sẽ khác với cách bạn từng học.
Nếu bạn là Tech Lead đang phải review code và giải thích vì sao một thiết kế tệ: Level 1.3 (Coupling/Cohesion) và Level 2 (SOLID) cho bạn ngôn ngữ chung để nói chuyện với team.
Nếu bạn đang refactor legacy code: đọc Level 1.3 → Level 3 → quay lại Level 4 khi pattern tự xuất hiện trong quá trình refactor.
Điều quan trọng nhất: đừng đọc Level 4 (Patterns) trước Level 1–3. Đó chính là cách học đã tạo ra hàng nghìn codebase over-engineered.
Quy ước trong tài liệu
- Thuật ngữ chuyên ngành giữ nguyên tiếng Anh: coupling, cohesion, interface, refactoring, trade-off…
- Code Go là code chính; TypeScript xuất hiện khi khác biệt ngôn ngữ đáng để so sánh.
- Mỗi ví dụ code có nhãn phiên bản (V1 → V2 → V3…) thể hiện quá trình tiến hóa, không phải kết quả cuối cùng.
// ❌đánh dấu code có vấn đề,// ✅đánh dấu code sau khi cải thiện — nhưng hãy nhớ: ✅ luôn có trade-off riêng của nó, được phân tích ở cuối mỗi chương.