01Tài liệu này dùng để làm gì
Rubric trả lời câu hỏi "tôi đang ở mức nào". Knowledge Map trả lời câu hỏi tiếp theo: "vậy tôi phải học cái gì để lên mức tiếp theo".
Đây là tài liệu dành cho người học, không phải cho người chấm. Mỗi Developer, Tech Lead và SA trong SU02 nên tự định vị mình trên bản đồ này và biết ba chủ đề tiếp theo cần trau dồi.
Cách dùng: sau khi có kết quả khảo sát, mỗi người khoanh vùng mức hiện tại của mình ở từng trụ, rồi lấy hàng ngay bên dưới mức đó làm danh sách học của quý. Không học dàn trải cả 6 trụ cùng lúc — chọn 2 trụ yếu nhất trong 3 trụ gate.
02Bản đồ kiến thức — 6 trụ × 4 mức
Trụ 1 — Architecture Design & Modeling
| Mức | Chủ đề cần nắm |
|---|---|
| SA0 | C4 model · layered vs modular · coupling & cohesion · hướng phụ thuộc (dependency direction) · SOLID ở mức module |
| SA1 | Domain decomposition · service granularity · API-first design · anti-corruption layer · shared kernel là bẫy |
| SA2 | Bounded context & context mapping · các kiểu coupling (static/dynamic, contract/semantic) · modular monolith vs microservices · Conway's Law và Inverse Conway Maneuver |
| SA3 | Fitness function · evolutionary architecture · kiến trúc đa hệ thống · platform thinking · golden path & paved road |
Trụ 2 — Quality Attributes — Performance & Scale
| Mức | Chủ đề cần nắm |
|---|---|
| SA0 | Latency vs throughput · p50/p95/p99 · caching cơ bản · N+1 query · index và khi nào index vô dụng |
| SA1 | Napkin math (TPS, dung lượng, băng thông) · load testing · connection pool · Little's Law · read replica |
| SA2 | Sharding & partition key · hot partition · Universal Scalability Law · backpressure & load shedding · tail latency amplification · CAP thực dụng · circuit breaker, bulkhead, timeout |
| SA3 | Capacity model nhiều năm · cost-per-transaction · thiết kế cho mức tải chưa từng gặp · chaos engineering · SLO/error budget |
Trụ 3 — Data & Integration Architecture
| Mức | Chủ đề cần nắm |
|---|---|
| SA0 | Normalization · transaction & isolation level · REST · sync vs async · khoá và deadlock |
| SA1 | Event-driven cơ bản · message queue · idempotency · retry & dead letter queue · API versioning · pagination đúng cách |
| SA2 | Eventual consistency · Saga · Outbox pattern · "exactly-once" là ảo tưởng · ordering & partition · CDC · schema evolution & backward compatibility |
| SA3 | Master data management & data ownership · data lineage · lakehouse vs warehouse · kiến trúc dữ liệu cho AI/RAG · data contract giữa các domain |
Trụ 4 — Technology & Platform Judgment
| Mức | Chủ đề cần nắm |
|---|---|
| SA0 | Hiểu sâu stack đang dùng và biết giới hạn thật của nó (không phải giới hạn nghe đồn) |
| SA1 | So sánh SQL vs NoSQL theo access pattern · khi nào cần cache, queue, search engine · đọc được benchmark mà không bị lừa |
| SA2 | TCO 3 năm · chi phí thoát ra (lock-in) · năng lực đội ngũ là một ràng buộc kiến trúc · khi nào không thêm công nghệ mới · managed service vs self-host |
| SA3 | Build vs buy có mô hình tài chính · technology radar · kiến trúc LLM/RAG trong ràng buộc dữ liệu khách hàng · đánh giá vendor |
Trụ 5 — Trade-off & Decision-making
| Mức | Chủ đề cần nắm |
|---|---|
| SA0 | Nhận diện có nhiều phương án cho cùng một bài toán |
| SA1 | ADR · liệt kê phương án có cấu trúc · phân biệt yêu cầu và giải pháp |
| SA2 | Quyết định dưới ràng buộc mâu thuẫn · nợ kiến trúc có chủ đích kèm điều kiện trả · quyết định đảo ngược được (Type 2) vs không đảo ngược được (Type 1) · reversibility là tiêu chí thiết kế |
| SA3 | Migration path cho legacy đang chạy · strangler fig · quản lý danh mục rủi ro kiến trúc · sunsetting có kế hoạch |
Trụ 6 — Communication & Influence
| Mức | Chủ đề cần nắm |
|---|---|
| SA0 | Vẽ bảng rõ ràng, ký hiệu nhất quán |
| SA1 | Viết tài liệu ngắn gọn · trình bày cho team · biết khi nào nên vẽ thay vì nói |
| SA2 | Dịch kỹ thuật sang ngôn ngữ chi phí và rủi ro · chịu phản biện và phản biện lại có lập luận · thuyết phục không dùng quyền lực |
| SA3 | Dẫn dắt đồng thuận đa bên · phát triển SA kế cận · viết được tài liệu tồn tại lâu hơn dự án |
03Lộ trình học 3 tháng — nhịp tuần
Mỗi tuần có ba thành phần cố định, tổng chi phí thời gian khoảng 4–5 giờ/người/tuần:
A · 2–3 giờ
Giải bài toán
Đề phát thứ 2. Làm cá nhân hoặc cặp. Vẽ tay trên giấy A3, không dùng AI, không tra internet. Mục tiêu là rèn khả năng suy luận trong điều kiện thiếu thông tin.
B · 1.5 giờ
Buổi review thứ 6
15 phút tóm tắt chương sách · 2 người trình bày 15 phút mỗi người · panel phản biện · 20 phút rút ra nguyên tắc chung.
C · 1 giờ
Đọc + AI review
1 chương sách/tuần. Người đã trình bày viết 1 ADR và 1 trang đối chiếu với AI review (giai đoạn này được dùng AI).
Phân bổ 12 tuần
| Tháng | Chủ đề | Bài toán | Đọc song song |
|---|---|---|---|
| Tháng 1 | Nền tảng thiết kế SA0 → SA1 | P01 Bounded context · P02 API contract 3 hệ thống · P03 Tách service đầu tiên khỏi monolith · P04 Vẽ C4 hệ thống thật của team mình | Fundamentals of Software Architecture ch.1–9 System Design Interview Vol 1 ch.1–4 |
| Tháng 2 | Ràng buộc chất lượng SA1 → SA2 | P05 Tải đỉnh 50× · P06 Nhất quán Customer 360 · P07 Dependency ngoài chết 2 giờ · P08 Curveball đổi ràng buộc giữa buổi | DDIA ch.1, 5, 6, 7 Release It! phần Stability Patterns |
| Tháng 3 | Đánh đổi & bối cảnh thật SA2 → SA3 | P09 Kiến trúc lại legacy đang chạy · P10 Build vs buy CDP · P11 Tích hợp LLM có ràng buộc dữ liệu KH · P12 Capstone từ portfolio SU02 | DDIA ch.8, 9, 11 The Hard Parts ch.2–4 |
Đầu ra mong đợi sau mỗi tháng
Đầu ra là bằng chứng học tập và thực hành, không phải tiêu chí tự động để gắn chức danh.
| Mốc | Năng lực trọng tâm | Đầu ra tối thiểu |
|---|---|---|
| Cuối tháng 1 | Nền tảng thiết kế | Vẽ được C4 cho một hệ thống thật · xác định được bounded context hoặc API boundary · viết một ADR ngắn có giả định và phương án bị loại. |
| Cuối tháng 2 | NFR, dữ liệu và failure | Định lượng được tải đỉnh và latency mục tiêu · giải thích consistency/integration choice · mô tả được cách xử lý timeout, retry, duplicate hoặc dependency failure. |
| Cuối tháng 3 | Trade-off và bối cảnh thật | Trình bày một capstone từ portfolio thật · so sánh ít nhất hai phương án theo chi phí, rủi ro và năng lực team · nêu migration path và điều kiện review lại. |
Cách đo: đối chiếu sản phẩm đầu ra và bằng chứng áp dụng (C4, ADR, NFR Specification, Integration Contract hoặc capacity estimate), chất lượng lập luận qua phiên review, và kết quả tự đánh giá trước/sau. Không dùng việc hoàn thành đủ tài liệu đọc làm bằng chứng duy nhất của tiến bộ.
Cá nhân hóa theo khoảng thiếu năng lực
Sau baseline, mỗi người chọn tối đa hai khoảng thiếu ưu tiên trong 12 tuần. Không yêu cầu mọi người học đồng đều cả sáu trụ.
| Tín hiệu từ rubric | Hướng ưu tiên | Hoạt động gợi ý |
|---|---|---|
| Yếu Trụ 1 hoặc chưa vẽ rõ ranh giới | Architecture Design | Làm lại P01/P03 · vẽ C4 hệ thống thật · review bounded context với TL. |
| Yếu Trụ 2 hoặc thiếu định lượng | Performance & Scale | Ôn napkin math · làm P05/P07 · tạo một NFR Spec và capacity estimate. |
| Yếu Trụ 3 hoặc xử lý consistency chưa tốt | Data & Integration | Làm P02/P06 · viết Integration Contract · phân tích duplicate, ordering và retry. |
| Yếu Trụ 4 hoặc chọn công nghệ theo thói quen | Technology Judgment | Viết một decision matrix · phân tích build vs buy · tính chi phí thoát ra. |
| Yếu Trụ 5 hoặc né trade-off | Decision-making | Viết ADR có phương án bị loại · ghi rõ điều đang hy sinh và điều kiện trả technical debt. |
| Yếu Trụ 6 hoặc khó thuyết phục | Communication & Influence | Trình bày 10 phút cho PM/TL · nhận phản biện · viết lại quyết định bằng ngôn ngữ chi phí và rủi ro. |
Nguyên tắc cá nhân hóa: giữ một nền tảng chung cho cả cohort, nhưng thay bài đọc, bài tập bổ sung và người review theo khoảng thiếu.
Nhịp thực tế: 12 tuần liên tục thường gãy ở tuần 5–6 khi dự án căng. Cam kết nên là 8 buổi bắt buộc trong 12 tuần, cho phép 4 tuần skip có kế hoạch. Thà ít mà đều.
04Nguồn học — thang bậc, không tham lam
| Mức | Tài liệu | Cách dùng trong chương trình |
|---|---|---|
| SA0→SA1 | Fundamentals of Software Architecture Mark Richards & Neal Ford | Sách vào cửa. Mỗi buổi một người tóm tắt 1 chương trong 10 phút. |
| SA0→SA1 | System Design Interview Vol 1 Alex Xu | Nguồn bài tập napkin math tốt nhất và dễ tiếp cận nhất. Dùng làm mẫu cho cách trình bày thiết kế. |
| SA1→SA2 | Designing Data-Intensive Applications Martin Kleppmann | Sách xương sống của chương trình. Chương 5–9 là phần Data & Scale. 1 chương/tuần trong 3 tháng đi hết phần cốt lõi. |
| SA1→SA2 | Release It! Michael Nygard | Phần failure patterns — đọc trước bài P07 về cascading failure. |
| SA2→SA3 | Software Architecture: The Hard Parts | Trade-off có phương pháp. Dùng cho tháng 3. |
| SA2→SA3 | Google SRE Book (miễn phí online) | Chương về SLO, error budget và handling overload. |
| Bổ trợ | AWS Well-Architected Framework · engineering blog của Netflix, Uber, Discord, Shopify, Stripe | Nguồn đáp án tham chiếu cho Problem Bank. Panel đọc trước mỗi buổi 30 phút. |
05Ba đường phát triển — không phải ai cũng phải thành SA
Đường A
Dev → SA
Dành cho người mạnh về hệ thống và dữ liệu, thích bài toán cấu trúc hơn bài toán con người. Ưu tiên trụ 1, 2, 3. Đây là cohort chính của Architecture Dojo.
Đường B
TL → Architecture Literacy
Không nhất thiết thành SA, nhưng phải đủ hiểu để phản biện SA và không dẫn team đi sai. Mục tiêu: SA1 đều 6 trụ, SA2 ở trụ 1 và 2.
Đường C
Dev → chuyên sâu kỹ thuật
Đi sâu một lĩnh vực (performance, data, security) thay vì đi rộng. Vẫn cần SA1 ở trụ 1 và SA2 ở lĩnh vực chuyên sâu của mình.
Số người vào cohort không cố định — quy mô điều chỉnh theo năng lực thực tế của nhóm đủ điều kiện Đợt 1, không phải một con số ấn định trước — và vào cohort cũng không có nghĩa là ra SA. Kỳ vọng thực tế sau 3 tháng: 2–3 người rõ ràng đi đường A, phần còn lại nâng được architecture literacy — đó đã là kết quả tốt.