“Framework là chi tiết, Database là chi tiết”. Câu nói nổi tiếng của Uncle Bob (Robert C. Martin) chính là linh hồn của Clean Architecture. Mục tiêu của nó là tạo ra một hệ thống mà Business Logic nằm ở trung tâm, hoàn toàn độc lập với các công cụ bên ngoài như Laravel, MySQL hay các API bên thứ 3.
#1. Cấu trúc các vòng tròn đồng tâm
Clean Architecture chia ứng dụng thành các lớp:
- Entities (Cốt lõi): Chứa các quy tắc nghiệp vụ quan trọng nhất (ví dụ: logic tính thuế, logic kiểm tra điều kiện vay vốn). Lớp này không được phụ thuộc vào bất kỳ thư viện nào.
- Use Cases (Interactors): Điều phối luồng dữ liệu từ Entities. Mỗi Use Case đại diện cho một hành động của người dùng (ví dụ:
RegisterUser,PlaceOrder). - Interface Adapters: Chuyển đổi dữ liệu giữa Use Cases và môi trường bên ngoài (Controllers, Presenters, Gateways).
- Frameworks & Drivers: Lớp ngoài cùng chứa Laravel, Database, Redis. Đây là nơi chứa code “rác” nhất và dễ thay đổi nhất.
#2. Quy tắc phụ thuộc (The Dependency Rule)
Sự phụ thuộc chỉ được trỏ vào bên trong. Lớp bên trong tuyệt đối không được biết gì về lớp bên ngoài. Ví dụ: Một Entity không được biết mình đang được lưu vào MySQL hay MongoDB.
#3. Tại sao Laravel Dev cần Clean Architecture?
Thông thường, chúng ta hay viết logic nghiệp vụ ngay trong Controller hoặc Model (Fat Models). Khi dự án lớn lên, việc bảo trì trở thành ác mộng. Clean Architecture giúp bạn:
- Dễ Unit Test: Bạn có thể test logic nghiệp vụ mà không cần khởi động Laravel hay kết nối DB.
- Linh hoạt: Bạn có thể đổi từ Blade sang React, từ MySQL sang PostgreSQL mà không cần sửa một dòng Business Logic nào.
#4.Câu hỏi nhanh
Câu hỏi: Nhược điểm lớn nhất của Clean Architecture khi áp dụng vào dự án nhỏ là gì?
Trả lời: Đó là Over-engineering và Sự cồng kềnh (Boilerplate). Để thực hiện đúng Clean Architecture, bạn phải tạo ra rất nhiều class, interface và các lớp chuyển đổi dữ liệu (DTOs, Mappers). Với một dự án đơn giản, điều này làm chậm tốc độ phát triển và gây khó khăn cho các lập trình viên Junior khi tiếp cận. Một Architect giỏi là người biết khi nào nên dùng “Pragmatic Laravel” (MVC tiêu chuẩn) và khi nào cần chuyển sang “Clean Architecture”.
Câu hỏi mẹo: Làm thế nào để thực hiện Dependency Inversion giữa Use Case và Repository trong Laravel? Trả lời:
- Khai báo một
UserRepositoryInterfaceở lớp bên trong (Domain layer). - Viết class
EloquentUserRepositoryimplement interface đó ở lớp bên ngoài (Infrastructure layer). - Sử dụng Laravel Service Container để bind Interface tới Implementation. Use Case chỉ việc inject Interface vào constructor.
#5. Kết luận
Clean Architecture không phải là một bộ luật cứng nhắc, nó là một tư duy. Hãy bắt đầu bằng việc tách logic nghiệp vụ ra khỏi Controller, bạn đã đi được 50% chặng đường tới “Clean” rồi.