Lời kết — Từ nguyên lý tới năng lực thiết kế

SOLID có giá trị khi nó thay đổi cách một đội phát triển quan sát hệ thống. Thay vì hỏi class này có đủ nhỏ hay có đủ interface hay chưa, team hỏi thay đổi nào đang lan rộng, client nào thật sự cần capability này, contract nào phải giữ và detail nào không nên định hình policy. Những câu hỏi ấy không đưa ra một cấu trúc duy nhất, nhưng chúng loại bỏ nhiều quyết định thiếu căn cứ.

Một codebase tốt vẫn có class concrete, CRUD service, direct module call và những nơi chưa cần port. Điều phân biệt nó với codebase xuống cấp là tính có chủ đích: boundary sâu được đặt nơi volatility và failure cost cao; cấu trúc đơn giản được giữ nơi change thấp; trigger xem xét lại được ghi rõ. Sự linh hoạt nằm ở phạm vi và mức đầu tư, không nằm ở việc cho phép contract đã công bố trở nên không trung thực.

Đừng bắt đầu capstone bằng cách tạo đủ folder domain, application và infrastructure. Hãy viết các business scenarios và invariant trước; xác định public API của Enrollment; vẽ source dependency hiện tại; chọn một outbound boundary có volatility thật; rồi refactor theo lát nhỏ. Mỗi lát phải giữ behavior bằng test trước khi thêm architecture rule.

Artifact cuối không chỉ gồm source code. Hãy nộp một decision record ngắn cho mỗi boundary quan trọng: evidence, lựa chọn, phương án đã loại, cost chấp nhận, correctness rule và trigger xem lại. Rubric ở bài tập Chương 9 chấm chính khả năng giải trình này.

Tuần đầu, chọn một change request gần đây và truy vết blast radius thật. Tuần thứ hai, viết characterization test quanh behavior cần giữ và loại một dependency không cần thiết. Tuần thứ ba, chọn một contract có nhiều implementation hoặc một interface phục vụ nhiều client để kiểm tra LSP/ISP. Tuần thứ tư, vẽ module dependency graph và thêm đúng một architecture rule bảo vệ risk cụ thể. Mỗi bước nhỏ tạo evidence tốt hơn một đợt tái cấu trúc toàn hệ thống theo khẩu hiệu.

• Change này thuộc reason to change nào, và code liên quan có nằm gần nhau không?

• Có variation axis đã được chứng minh hay abstraction chỉ dự đoán tương lai?

• Implementation mới có giữ observable contract đối với mọi client hợp lệ không?

• Client đang phụ thuộc đúng capability cần dùng hay toàn bộ surface của provider?

• Source dependency hướng về policy hay detail đang sở hữu contract?

• Test đang bảo vệ behavior ở boundary nhỏ nhất tạo đủ confidence không?

• Cấu trúc thêm vào mua được điều gì, và khi nào quyết định cần được xem xét lại?

Nếu team có thể trả lời những câu hỏi này bằng code, test và lịch sử thay đổi, SOLID đã trở thành năng lực thiết kế thay vì kiến thức để nhắc lại trong phỏng vấn.