Giao diện
Architect Patterns — Kiến trúc Hệ thống
Mọi hệ thống phần mềm đều bắt đầu từ một quyết định kiến trúc. Quyết định đó không phải chọn công nghệ "hot" nhất — mà là chọn đúng trade-off cho bối cảnh cụ thể của tổ chức, team size và business domain. Một startup 5 người chọn microservices từ ngày đầu sẽ chết vì operational overhead trước khi kịp tìm product-market fit. Một enterprise 500 kỹ sư giữ monolith quá lâu sẽ tê liệt vì deployment bottleneck.
Phase này trang bị cho bạn khả năng đánh giá và lựa chọn kiến trúc dựa trên engineering reasoning — không phải dựa trên blog posts hay conference talks.
Lộ trình học
Bốn module được sắp xếp theo thứ tự phụ thuộc kiến thức. Module 1 là nền tảng bắt buộc, các module sau xây dựng lên trên kiến thức đó.
Nội dung
Nền tảng kiến trúc
| Module | Chủ đề chính | Độ khó |
|---|---|---|
| Monolith vs Microservices | Trade-offs thực tế, Strangler Fig, Service Mesh, Team Topology | Intermediate |
| Distributed Transactions | 2PC, 3PC, Saga Pattern, Outbox Pattern, Compensating Transactions | Advanced |
Patterns nâng cao
| Module | Chủ đề chính | Độ khó |
|---|---|---|
| Advanced Patterns | CQRS, Event Sourcing, DDD Tactical Patterns, Hexagonal Architecture | Advanced |
| Serverless & Edge | FaaS, Cold Start, Edge Computing, CDN Edge Functions | Intermediate |
Triết lý thiết kế
Evolutionary Architecture — Kiến trúc tốt nhất là kiến trúc có thể tiến hóa. Không có kiến trúc "hoàn hảo" — chỉ có kiến trúc phù hợp với giai đoạn hiện tại và có khả năng thay đổi khi yêu cầu thay đổi.
Complexity Budget — Mỗi pattern thêm vào hệ thống đều có giá. CQRS, Event Sourcing, Service Mesh — tất cả đều mạnh mẽ, nhưng chỉ khi complexity mà chúng giải quyết lớn hơn complexity mà chúng mang đến.
Conway's Law — Kiến trúc hệ thống phản ánh cấu trúc tổ chức. Đừng thiết kế microservices nếu team không được tổ chức theo domain boundaries.