1.

Giá trị cốt lõi của Clean Architecture

• Phần nào của hệ thống phần mềm nên được bảo vệ nhiều nhất?
• Tại sao logic nghiệp vụ (business rules) lại cần “độc lập” với framework, UI hay database?
• Khi code của chúng ta phụ thuộc nhiều vào chi tiết kỹ thuật (framework, DB, UI), rủi ro dài hạn
sẽ là gì?

2. Thái độ nghề nghiệp

• Theo bạn, viết code “sạch” có phải để thoả mãn kỹ thuật, hay là một cách thể hiện trách nhiệm
với đồng đội trong tương lai?
• Nếu một đồng đội khác kế thừa hệ thống sau 2 năm, họ sẽ cảm thấy thế nào khi đọc code của
chúng ta?
• Bạn nghĩ “kiến trúc sạch” có giống như “lãnh đạo tốt” – tạo ra môi trường rõ ràng, ít phụ thuộc,
khuyến khích phát triển – hay không?

3. Hành động thực tiễn

• Nếu chọn một module nhỏ trong dự án để thử refactor theo Clean Architecture, bạn muốn chọn
phần nào?
• Làm thế nào để chúng ta đo được lợi ích thực sự (ví dụ: dễ test hơn, dễ thay đổi hơn) khi áp
dụng?
• Câu hỏi cuối cùng: Bạn muốn code mình viết để lại di sản như thế nào?

4. Khơi gợi từ trải nghiệm thực tế

• Bạn đã từng gặp dự án nào mà việc thay đổi một dòng code kéo theo sửa rất nhiều nơi khác
chưa?
• Điều gì khiến một hệ thống đang chạy tốt bỗng trở nên khó mở rộng hoặc khó bảo trì?
• Nếu một framework phổ biến mà chúng ta dùng hôm nay bị thay thế, hệ thống của chúng ta sẽ
bị ảnh hưởng đến mức nào?

5. Nhận thức về nguyên tắc

• Bạn hiểu thế nào về nguyên tắc “mũi tên phụ thuộc luôn hướng vào trong”?
• Nếu chia hệ thống thành các vòng tròn (Entities, Use Cases, Interface Adapters, Frameworks),
bạn nghĩ phần nào có thể thay đổi nhiều nhất? Phần nào nên ổn định lâu dài nhất?
• Trong thực tế, áp dụng SOLID quá mức có thể gây hại không? Làm sao để cân bằng giữa
“clean” và “pragmatic”?

Phạm vi nội Chương Nội dung khai thác Lý do lựa chọn Tỉ lệ bao phủ
dung tương
ứng
NỀN TẢNG 1–2 - Khái niệm kiến trúc vs Giúp team hiểu ~6%
thiết kế “tại sao cần
Clean
- Hai giá trị của phần mềm Architecture”,
(behavior & structure) khơi gợi từ nỗi
đau thực tế.
Phạm vi nội Chương Nội dung khai thác Lý do lựa chọn Tỉ lệ bao phủ
dung tương
ứng
NGUYÊN SOLID Khung tư duy nền
TẮC CỐT tảng để code ~15%
LÕI 7–11 maintainable, dễ
dẫn dắt bằng ví
dụ.
NGUYÊN 12–13 Component principles Bổ trợ cho
TẮC TỔ (Cohesion, Coupling) SOLID, giúp hình ~6%
CHỨC dung cách chia
module.
- Định nghĩa kiến trúc- Trọng tâm Clean ~15%
Nguyên tắc độc lập Architecture, hình
(framework, UI, DB, thành “tư duy
KIẾN TRÚC
14–18 external) vòng tròn trong/
ỨNG DỤNG
ngoài”.
- Boundaries & Dependency
Rule
19–21 - Business Rules là cốt lõi Đây là “linh hồn”
của sách, giúp ~9%
- Screaming Architecture- team hình dung
KIẾN TRÚC
CLEAN tổng thể.
- Clean Architecture diagram
(tổng hợp Onion/
Hexagonal/Layers)
22–33 - Presenter & Humble Object Bổ sung minh
họa, nhưng không ~32%
CHI TIẾT & - Partial Boundaries phải tinh thần cốt
VÍ DỤ lõi. Có thể dùng
- Case studies & Variations khi cần ví dụ thực
tế.
34 - “The Missing Chapter” - Gắn tinh thần
trách nhiệm nghề nghiệp Clean ~3%
Architecture với
KẾT LUẬN leadership: code
& THÁI ĐỘ sạch là sự tôn
trọng đồng đội và
tương lai hệ
thống.
Tổng kết
• Sách đầy đủ: 34 chương = 100% nội dung.
• Khai thác trọng tâm: Ch. 1–2, 7–13, 14–18, 19–21, 34 → khoảng 15 chương (~45%).
• Tinh thần cốt lõi được bao phủ: ~80–90%.
• Các chương còn lại (~55%): chủ yếu minh họa, biến thể, case study → có thể bổ sung khi team
đã quen.