Tổng Quan

SOLID không ra đời để làm code trông "học thuật" hơn. Nó ra đời từ một nỗi đau rất thực dụng: phần mềm càng sống lâu, càng nhiều người sửa, càng dễ biến thành một khối khó đổi.

Lúc mới viết, code thường còn nhỏ. Sau vài tháng, một yêu cầu mới có thể kéo theo sửa nhiều module; sửa checkout lại vỡ email; đổi database lại ảnh hưởng nghiệp vụ; muốn viết test nhưng service kéo theo quá nhiều chi tiết hạ tầng. Đó là lúc team bắt đầu cần nguyên tắc thiết kế, không chỉ cần cú pháp.

• ▸Dự án càng sống lâu thì chi phí thay đổi càng quan trọng.
• ▸Team càng đông thì ranh giới trách nhiệm càng cần rõ.
• ▸Yêu cầu càng hay đổi thì dependency cứng càng dễ gây chậm và lỗi.

Các nguyên tắc đứng sau SOLID đến từ cộng đồng thiết kế hướng đối tượng (OOP) cuối thập niên 1990 và đầu thập niên 2000. Robert C. Martin, thường được biết tới với tên Uncle Bob, phổ biến chúng trong bài Design Principles and Design Patterns năm 2000 và các sách về Agile/OOP sau đó.

Ban đầu chúng là các nguyên tắc thiết kế lớp hướng đối tượng. Sau này Michael Feathers được ghi công vì đề xuất acronym SOLID, giúp 5 nguyên tắc dễ nhớ hơn:

SOLID hữu ích nhất khi chi phí thay đổi bắt đầu lớn hơn chi phí thiết kế. Nói cách khác: nếu phần mềm còn sống lâu, còn đổi yêu cầu, còn nhiều người chạm vào, thì việc giảm coupling và tách trách nhiệm sẽ tiết kiệm công về sau.

Một hiểu lầm phổ biến là "đã học SOLID thì phải áp dụng đủ cả 5 nguyên tắc ở mọi nơi". Cách nghĩ đó dễ đẩy team vào over-engineering: nhiều class, nhiều interface, nhiều file, nhưng luồng nghiệp vụ lại khó đọc hơn.

• ▸SOLID là bộ câu hỏi thiết kế, không phải checklist để tích đủ.
• ▸Có module chỉ cần SRP: tách trách nhiệm cho dễ đọc và dễ test.
• ▸Có ranh giới I/O nên ưu tiên DIP: database, email, payment, API ngoài.
• ▸OCP, LSP, ISP đáng đầu tư hơn khi hệ thống có nhiều biến thể và nhiều client.

Áp dụng SOLID giống như trả một khoản chi phí thiết kế trước để giảm chi phí thay đổi sau này. Câu hỏi không phải "SOLID tốt hay xấu?", mà là "với dự án này, khoản chi đó có đáng không?"

SOLID không chỉ là quyết định kỹ thuật. Nó là quyết định của team. Nếu team chưa cùng hiểu interface, dependency injection, unit test, refactor và code review, việc yêu cầu "áp dụng SOLID" có thể tạo ra 5 kiểu code khác nhau.

• ▸Team senior, có test và review đều: có thể áp dụng sâu ở module lõi và ranh giới hạ tầng.
• ▸Team hỗn hợp: chọn 1-2 nguyên tắc dễ thống nhất trước, viết guideline ngắn và review bằng ví dụ.
• ▸Team mới hoặc deadline gấp: ưu tiên đọc dễ, test được phần quan trọng, tránh coupling lộ rõ.
• ▸Team legacy: không refactor hàng loạt; chọn điểm đau, viết characterization test, cải thiện dần.

Trước khi đưa SOLID vào một dự án, team có thể dùng khung 4 bước này trong buổi technical planning hoặc trước một đợt refactor:

• ▸Bước 1: chấm bối cảnh dự án - tuổi thọ, tần suất đổi yêu cầu, số người cùng sửa, rủi ro lỗi.
• ▸Bước 2: chấm năng lực team - OOP, interface, unit test, refactor, code review.
• ▸Bước 3: chọn mức áp dụng - nhẹ, vừa, hoặc mạnh; ghi rõ nguyên tắc nào ưu tiên trước.
• ▸Bước 4: đo lại sau 2-4 tuần - PR có dễ review hơn không, test có dễ viết hơn không, bug có giảm không.

Bài tổng quan chỉ giúp bạn ra quyết định có nên học và áp dụng SOLID ở mức nào. Các bài sau mới đi vào từng nguyên tắc bằng ví dụ TypeScript trước/sau:

• ▸Bài 2: Single Responsibility - tách trách nhiệm để module chỉ có một lý do chính để đổi.
• ▸Bài 3: Open/Closed - mở rộng bằng đa hình, Strategy hoặc registry thay vì sửa nhánh if cũ.
• ▸Bài 4-6: LSP, ISP, DIP - giữ lời hứa kế thừa, chia interface nhỏ, đảo chiều phụ thuộc.
• ▸Bài 7-8: áp dụng tổng hợp và refactor một module legacy có test đỡ lưng.