NestJS Foundation

Thời gian: 6 buổi × 90 phút = 9 giờ
Output: API module hoàn chỉnh (Auth + CRUD) + ADR kiến trúc

Vấn đề

Backend Node.js thuần dễ thành spaghetti khi scale. Làm sao tổ chức code có cấu trúc, testable, và dễ maintain khi team lớn dần? NestJS mang OOP + DI từ Angular sang Node, nhưng dùng sai dễ thành over-engineering.

Bảng quyết định

Lựa chọn	Khi nào dùng	Khi nào KHÔNG dùng
NestJS	Project lớn, team > 1 dev, cần DI, cần testable	API đơn giản 3–5 endpoint (dùng Express/Fastify thuần)
Express thuần	Prototype nhanh, API đơn giản, 1 dev	Project scale, cần structure rõ ràng
Fastify thuần	Performance cực cao, không cần DI	Cần ecosystem plugin (NestJS wrap sẵn)
Clean Architecture / DDD	Business logic phức tạp, domain rõ ràng	CRUD đơn giản, không có business rules phức tạp

Quyết định mặc định

NestJS cho mọi project backend mới trong lộ trình này. Express/Fastify thuần chỉ khi prototype < 1 tuần.

Anti-pattern

Tạo module cho mỗi file → over-modularization.
Dùng @Injectable() cho mọi class dù không cần inject.
Bỏ qua Pipes validation → validate thủ công trong controller.
Không viết unit test vì “NestJS phức tạp” — DI sinh ra để dễ test.

Checklist chi tiết

Dependency Injection

Hiểu IoC (Inversion of Control) — tại sao DI giúp test
@Injectable() vs @Module() providers
Constructor injection vs Property injection
Custom Provider: useClass, useValue, useFactory
Scope: DEFAULT, REQUEST, TRANSIENT — khi nào dùng cái nào

Guards, Interceptors, Pipes

Guards: @CanActivate — kiểm tra quyền trước khi vào handler
Interceptors: transform response / log / cache / timeout
Pipes: ValidationPipe (class-validator) + TransformPipe
Exception Filters: bắt lỗi toàn cục vs cục bộ
Middleware vs Interceptor vs Guard — phân biệt rõ

Clean Architecture / DDD cơ bản

Phân tầng: Controller → Service → Repository → Entity
Domain Entity: chứa business logic, không phụ thuộc framework
Repository Pattern: abstract DB access, dễ test/mock
DTO (Data Transfer Object): validate + type-safe giữa các tầng
Không để Service gọi trực tiếp Prisma trong Controller

War Story: Guard bypass qua internal call

Bối cảnh: Dev A viết Guard check @Roles('admin') trên route. Dev B gọi trực tiếp Service method từ một Service khác — bypass Guard hoàn toàn.

Quyết định: Guards chỉ bảo vệ HTTP layer. Business logic phải tự check authorization trong Service/Domain layer. Không tin bất kỳ input nào từ bên ngoài.

Bài học: Authorization phải ở tầng Domain, không chỉ ở tầng HTTP. Guard là lớp phòng thủ thứ nhất, không phải lớp duy nhất.