Quá nhiều class Use Case khi triển khai Clean Architecture

Duc_Manh_Pham · December 14, 2023, 9:24am

Chào mọi người, mình đang cố gắng ứng dụng Clean Architecture.

Trong dự án Ứng dụng di động của mình, có khoảng 6 entity khác nhau và mỗi repository cho thực thể có ít nhất 4 phương thức, thường là get, add, delete, update (CRUD) để truy cập chúng… vì vậy, 6 * 4 = 24.

Theo như mình tham khảo 1 số triển khai Clean Architecture, mình sẽ cần 24 class Use Case.

Điều này là một số rất lớn các class so với chỉ có 6 Controller trong MVC, và dù có các class Use Case rồi, mình vẫn phải giữ 6 class Controller đó và tạo sự phụ thuộc giữa các Controller và Use Case.

Liệu mình thực sự cần phải tạo ra 24 Use Case không? Nó dường như chỉ là 1 lớp proxy với 1 lượng code rất lớn !
Mình thấy mọi người đều dùng class để khởi tạo Use Case, liệu dùng function cho tinh gọn hơn có ổn không ?
Nếu chỉ có những thao tác CRUD, thì kết luận rằng Clean Architecture không phù hợp với ứng dụng này do ít logic nghiệp vụ liệu có đúng ?
Mình nghĩ đến việc tạo ra 1 Use case bao quát hơn, như “Thao tác với Sản phẩm”, thay vì tách ra làm 4 class “Thêm SP, Xóa SP, Sửa SP, Đọc SP”, nhưng như thế sẽ vi phạm nguyên tắc Single responsibility và tăng sự khó hiểu. Điều này là không nên đúng không nhỉ ?

Rất mong nhận được lời khuyên ạ !

anonymous273 · December 8, 2023, 9:13am

không, bạn chỉ cần tạo 6 use cases, mỗi use case 4 methods
chả phải class cũng dùng constructor (a.k.a 1 function) để khởi tạo? ngoài ra thì bạn có thể xài các builder patterns để khởi tạo. chắc đây là ý của bạn?
không. thường Clean Architecture là cho dự án to và đi dài hạn vì clean giúp dễ maintain hơn. clean giúp bạn bỏ ra 5 sức để đi được 10 bước thay vì 10 sức để đi 10 bước. tức nếu bạn đang build 1 project to, lâu dài dù nó đơn giản chỉ là CRUD, xài clean sẽ giúp bạn đạt điều đó.
bạn đang chưa hiểu đúng về SRP. giải thích thì khá dài dòng nhưng hiểu cơ bản SPR không đi chi tiết tới 1 hàm xử lý cái gì -> thay đổi việc xử lý là vi phạm, mà 1 hàm/class giải quyết vấn đề gì (trừu tượng hơn). nếu các hàm đều giải quyết chung 1 bài toán là quản lý sản phẩm thì welp, SPR vẫn được thoả mãn nên bạn tách ra vậy vẫn đúng.

tonghoangvu · December 8, 2023, 11:41am

Đúng, clean architecture tạo ra cho các hệ thống có domain phức tạp. Backend có nghiệp vụ đơn giản và cả frontend đều không cần (và không nên) dùng clean architecture.

library · December 14, 2023, 5:47am

Cậu cần 24 use cases (nếu như cậu chỉ dùng CRUD), nhưng cậu có thể tổ chức thành ít class hơn, như @anonymous273 đã đề cập.

Cơ mà, tớ rất nghi ngờ việc cậu cần tới từng đó use case. Vì các entity thường tạo thành business model, và nhìn từ phía người dùng (use case), cậu thao tác với model, không phải entity.
Cậu có entity book, entity tag, entity publisher, entity author,… nhưng cậu chỉ có 1 model book. Các use case của cậu sẽ là CRUD trên book, không phải CRUD trên từng entity. Như thế, cậu thực ra chỉ có 4 use case.

Tất nhiên, cậu sẽ vẫn có thể có 6 repository (tương ứng với 6 bảng/entity ở database).

Tớ hiểu là cậu hiểu nhầm mỗi class sẽ chỉ có 1 method duy nhất để implement use case, nên cậu mới có câu hỏi này.

Đó là cách tổ chức thôi cậu. Class trong OOP là cách tổ chức chương trình rất hiệu quả.
Kể cả cậu dùng function (với ngôn ngữ không có class/object), cậu cũng không thể ném hết function vào 1 file duy nhất. Cậu vẫn phải tổ chức nó theo các file, mỗi file có các function có liên hệ logic nào đó với nhau.

Hẳn nhiên rồi cậu Sẽ là over-engineering nếu cậu dùng clean architect cho app chỉ có lèo tèo vài API. Keep It Simple, Stupid!
Với CRUD, cậu có thể lựa chọn kiến trúc đơn giản hơn, và re-architect nếu trong tương lai cậu cần cài đặt các business logic phức tạp hơn.

Cậu có thấy khó hiểu khi nhìn thấy 1 class có tên là “Thao tác với Sản phẩm” không?
Bằng tên class, bất cứ ai cũng hiểu đó là class có duy nhất 1 nhiệm vụ là “thao tác với sản phẩm”. SRP vẫn áp dụng ở đây, khi cậu không gọi nó là “Thao tác với Sản Phẩm và Khách Hàng” và implement 2 business flow ở đó.

Hope it helps!