Cá nhân mình rất đồng ý với quan điểm 1 entity sẽ có n Repository. Thực ra mục đích chính của mình khi sử dụng Interface ở đây là để tầng use-case khi sử dụng các method của Repository sẽ không phụ thuộc vào việc implement nó như thế nào, mà sẽ sử dụng thông qua method signature của interface, để từ đó nếu chuyển từ MySQL sang PostgreSQL chẳng hạn thì chỉ có tầng infrastructure là bị ảnh hưởng còn từ tầng use-case cho đến tầng domain hoàn toàn không bị ảnh hưởng - ở đây mình muốn tránh cả quan hệ phụ thuộc giữa các tầng domain, use-case và infrastructure với nhau.

Rất cảm ơn bạn đã phản hồi, mình rất mong nhận được thêm nhiều đóng góp nữa từ bạn. 😀

Mình có để một số link mà mình tham khảo ở cuối bài viết, nếu bạn đọc kỹ hơn sẽ thấy nhé ^^ Cảm ơn bạn

@Fuzzy thks bạn nhiều nha 🤩

Chắc ý họ là sau lại tạo 1 cái UserCacheRepository implement IUserInterface rồi viết lại riêng cho cache thôi bác 😆

Với cả interface trong repo chưa hẳn cần thiết mọi lúc nên cân nhắc loại bỏ nó, hiếm khi nào có chuyện đồng thời logic lưu data vào cả 2 db y hệt nhau tại cùng thời điểm Repository không nên có quan hệ 1 1 với entity nó nên là quan hệ 1 nhiều 1 entity nên có nhiều repo Mỗi repo nên thực hiện 1 nghiệp vụ logic cụ thể vì trong thực tế logic sẽ không dừng ở cái đống getBy... của bạn Giờ mà logic query nó phình ra thì cái repo của bạn cũng phình theo khiến cái repo đó quá đa nhiệm Bên cạnh đó trong domain thì service mình nghĩ chỉ nên đóng vai trò giao tiếp giữa các domain Còn chi tiết logic nên nằm trong action class

matrix bạn ạ.

dịch với xào bài ko ta, cái ảnh cũng nhỏ + nhoè nữa

@Giahuy tks, t chạy được rồi, trong func cudaError_t cardProperties() có 1 cái warning t cũng fix luôn, sửa dòng cudaError_t cudaStatus; -> cudaError_t cudaStatus = cudaSuccess; là đc.

Theo em biết thì các value object sẽ được nhóm trong 1 aggregate và các aggregate này nó sẽ đảm nhiệm các business logic cụ thể. Anh có thể chia sẻ kinh nghiệm về cách xác định nên tạo value object nào và nên giới hạn số lượng value object ạ

mình sẽ lưu file ở dạng <tên file>.cu xong rồi compile bằng 2 dòng lệnh( khi compile mở terminal lên rồi vô đúng thư mục bạn đã lưu code):

1)nvcc <tên file>.cu
2)./a.out

@naotaliot22 okie e nhé

Trong đoạn code cuối bài, nếu mình chạy trên máy bình thường thì lưu ở file gì và compile như nào bạn nhỉ.

Ví dụ mình muốn sử dụng các tools logging hoặc các common libs ở tầng domain service thì như nào nhỉ

Đọc đến chỗ tạo abstract class IUserRepository, mình tưởng là app nó có nhiều hơn một database để lưu trữ user chứ, chẳng hạn như lưu user trong cache để giảm tải cho database, và muốn repository có cùng 1 interface cho cache và database. Nhưng xuống tới phần implement thì lại base cho các repository khác nhưng cùng một database, từ phía structure (không liên quan tới business) thì cách chia repository này có ích gì nhỉ? nghe như có mùi "giải quyết vấn đề không tồn tại", nó sẽ tạo ra vấn đề khác.

Sao mình tính ra B1 là 2.1636 vậy

derived table chứ nhỉ, làm gì có drive table?

@maitrungduc1410 Vâng anh. Cảm ơn anh nhiều nhé.

ok

@devil_boom_129 ,cho hỏi cái ide web sao mình không thể run file web trong đó thế,gitlab đó

rồi sâu chưa