"À ngoài ra có một điểm nữa là mình vẫn chưa tìm hiểu được là liệu dùng SDK API thì có support việc truyền vào data ở dạng Object hay không hoặc nếu truyền vào nhiều string thì nó có mã hóa hết các string 1 lần rồi mới mã hóa data key hay không. Nếu nó cứ mã hóa 1 string thì phải call KMS 1 lần thì sẽ không tốt cho performance." => phần này không biết chủ thớt đã có câu trả lời chưa ạ?
tbl_per_relationship: là bảng lưu mối liên hệ giữa người dùng và nhóm quyền hạn. Mục đích của bảng này không phải là để một người dùng có nhiều nhóm quyền mà để không phải truy vấn lại bảng user chứa thông tin nhạy cảm như username và password. Bạn cũng có thể bỏ qua bảng này và liên hệ trực tiếp giữa bảng user và permision luôn, nhưng mình khuyên bạn nên sử dụng thêm bảng này vì có nhiều trường hợp user có nhiều quyền hạn.
=> tbl_per_relationship có diễn giải nhưng ko có hình ảnh & dữ liệu tbl_per_relationship
Onion cho rằng mỗi Object model có service riêng, application service lại sử dụng lại các object services
Clean gộp application + object service vào (đồng thời cũng chia nhỏ) những use cases.
-> onion về cơ bản chỉ là vẽ chi tiết hơn Business Logic Layer, vẽ lại n-tiers dưới góc độ DDD. Việc vẽ các vòng tròn làm tăng tính trực quan mà thôi.
-> clean thì mang tính cách mạng hơn. Việc tập trung vào UC, coi UC là chủ thể độc lập có nghĩa là đóng gói các chức năng riêng biệt so với việc nhét một mớ chức năng vào 1 service. vì thế clean thường được implement bằng CQRS - Mediator, đồng thời cũng mang cách thức của Aspect Programming. Nó giúp lập trình viên khi viết các interface thoải mái hơn, thoát ra ngoài tư duy OOP.
mình thấy bạn có thể thêm bài viết triển khai trực tiếp multi broker thì sẽ hay hơn nữa vì khi triển khai qua các container hiệu năng của việc truyền tải dữ liệu sẽ bị giảm xuống
THẢO LUẬN
"À ngoài ra có một điểm nữa là mình vẫn chưa tìm hiểu được là liệu dùng SDK API thì có support việc truyền vào data ở dạng Object hay không hoặc nếu truyền vào nhiều string thì nó có mã hóa hết các string 1 lần rồi mới mã hóa data key hay không. Nếu nó cứ mã hóa 1 string thì phải call KMS 1 lần thì sẽ không tốt cho performance." => phần này không biết chủ thớt đã có câu trả lời chưa ạ?
tbl_per_relationship: là bảng lưu mối liên hệ giữa người dùng và nhóm quyền hạn. Mục đích của bảng này không phải là để một người dùng có nhiều nhóm quyền mà để không phải truy vấn lại bảng user chứa thông tin nhạy cảm như username và password. Bạn cũng có thể bỏ qua bảng này và liên hệ trực tiếp giữa bảng user và permision luôn, nhưng mình khuyên bạn nên sử dụng thêm bảng này vì có nhiều trường hợp user có nhiều quyền hạn.
=> tbl_per_relationship có diễn giải nhưng ko có hình ảnh & dữ liệu tbl_per_relationship
Bài viết hay quá ạ !!!
ở phần Front-end + API Gateway + AWS Lambda + AWS Cognito, ở đây nhược điểm anh có nói về scale, anh nói rõ hơn đc không ạ? Em xin cảm ơn.
^^ Cảm ơn em đã đọc.
great
mình thấy bạn có thể thêm bài viết triển khai trực tiếp multi broker thì sẽ hay hơn nữa vì khi triển khai qua các container hiệu năng của việc truyền tải dữ liệu sẽ bị giảm xuống
hay quá shop ơi
bài viết hay, cảm ơn anh đã chia sẻ
sử dụng b oi :v
🫠🫠🫠quầu hay z
hay qua a
bai viet that huu ich a
Bác ở trên tối cổ còn tôi 2024 mới đọc nên chắc gọi là hố đen cổ
rất hay, cảm ơn tác giả
good
many thanks
useful
Thanks for your sharing