đăng bài chán thế chép lại code thôi cũng sai nữa cái view 2fa.blade.php cũng k up lên, lại phải vào bài chính chủ xem từ đầu, đăng bài thì có tâm một tí nhá

haha, thực hành ngay thôi

Cảm ơn những kinh nghiệm quý báu của anh. Anh có thể cho em xin tài liệu qua mail: nhabanoi98@gmail.com được ko ạ. Em cảm ơn anh nhiều !

Tuyệt vời

khá khó hiểu, nhưng chắc sau này sẽ hiểu

Cảm ơn bạn đã đặt câu hỏi, về phần nhúng database instance thì mình sẽ thực hiện nó ở class implement thuộc tầng infrastructure, đây là ví dụ nhé bạn: https://github.com/tuananhhedspibk/NewAnigram-BE-DDD-Public/blob/main/src/infrastructure/repository/user/index.ts#L27

tài liệu nói đến thể cũng kh hiểu ư ))

Nếu dùng transaction xuyên suốt các repo (điều khiển ở usecase layer) thì sao nhỉ?

Các abstract interface method không nhúng database instance vào thì làm sao thực hiện được việc đó? còn nếu chèn vào thì làm sao giữ được tính louse-coupling cho các DB khác nhau taaaa?

Với logging thì mình nghĩ vẫn sẽ là import thẳng vào domain service trực tiếp được, nhưng nên hạn chế vì ở tầng main theo mình thì không nên để nó phụ thuộc quá nhiều vào các công nghệ bên ngoài mà chỉ nên thuần tuý là business logic.

Cảm ơn bạn đã phản hồi, cá nhân mình thì thấy Value Object sẽ phù hợp với những "giá trị" đặc trưng riêng của hệ thống. Mình lấy ví dụ với hệ thống kho vận thì Value Object có thể là RFID, hay hệ thống quản lí nhân viên công ty thì Value Object có thể là mã số của từng nhân viên, do ở các hệ thống này các "gía trị" như RFID hay mã số nhân viên sẽ có một vài điều kiện ràng buộc hoặc phải có một bộ validation riêng, nên để phản ánh đúng nghiệp vụ của hệ thống thì các "giá trị đặc trưng" như vậy nên được đưa vào Value Object. 😀

@minhnb10121994 Mình đã trả lời ở ý https://viblo.asia/c/5OXLAll8JGr rồi nhé, cảm ơn các bạn đã phản hồi 😃

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 ạ