kiến thức Chia sẻ kinh nghiệm về Repository pattern

Tôi đọc hết cả #1 thì thú thật tôi không hiểu gì hết, quá nhiều từ viết tắt, cũng không đặt trong trường hợp nào rõ ràng cụ thể, anh chỉ đang bàn về 1 cái pattern thôi? Hay anh muốn bàn về cái pattern đó sau khi đã được hiện thực hoá trên 1 cái môi trường nào đó, trên 1 ngôn ngữ lập trình cụ thể nào? Người tamuốn tranh luận cũng không biết bắt nguồn từ đâu
 
Có chuyển cũng chỉ chuyển từng phần nào đó cần thiết.

Ở đây có bạn nào “may mắn” được/bị làm việc với các hệ thống “có vẻ” là microservices sẽ hiểu cảm giác khổ sở vê lờ khi biz nó đòi hỏi một cái feature gì đó mà cái “microservices “ hiện tại nó không đáp ứng được.

Khi đó lại phải ngồi nghĩ cách cheating, hacking, adhoc… blabla để workaround được cái yêu cầu. Lúc này chỉ muốn đập cmn hết đi làm monolith.

Cái này là hệ quả của việc triển khai “microservices” theo ý chí của tech mà không xét đến biz.

+1 cho bác

Đang làm với 1 hệ thống design ban đầu là module mono. Nhưng sếp mới vào áp dụng giải pháp micro service. Cuối cùng thành 1 mớ hỗ độn, trong khi người cầm key chính maintain vẫn là mình :sad:

Cay hơn là sếp đưa ra giải pháp block vài phút, để 2 service nói chuyện với nhau theo kiểu settimeout. Max ping cho 1 giải pháp bét sô nu sừn.
 
+1 cho bác

Đang làm với 1 hệ thống design ban đầu là module mono. Nhưng sếp mới vào áp dụng giải pháp micro service. Cuối cùng thành 1 mớ hỗ độn, trong khi người cầm key chính maintain vẫn là mình :sad:

Cay hơn là sếp đưa ra giải pháp block vài phút, để 2 service nói chuyện với nhau theo kiểu settimeout. Max ping cho 1 giải pháp bét sô nu sừn.

Sếp mới bác Master Microservices đó bác. Chắc không biết Monolithic là gì ấy bác.
 
+1 cho bác

Đang làm với 1 hệ thống design ban đầu là module mono. Nhưng sếp mới vào áp dụng giải pháp micro service. Cuối cùng thành 1 mớ hỗ độn, trong khi người cầm key chính maintain vẫn là mình :sad:

Cay hơn là sếp đưa ra giải pháp block vài phút, để 2 service nói chuyện với nhau theo kiểu settimeout. Max ping cho 1 giải pháp bét sô nu sừn.
Làm việc với microservices cũng đủ lâu để rút dc nhiều kinh nghiệm đau thương. Giờ ông nào mà cứ đòi microservices là cứ phải debate chán chê, chứng minh value mang lại khi áp dụng microservices mới làm. :shame:

https://scs-architecture.org/ -> Bây giờ mới nghiệm ra cái này mới là chân lý. :shame:
 
Làm việc với microservices cũng đủ lâu để rút dc nhiều kinh nghiệm đau thương. Giờ ông nào mà cứ đòi microservices là cứ phải debate chán chê, chứng minh value mang lại khi áp dụng microservices mới làm. :shame:

https://scs-architecture.org/ -> Bây giờ mới nghiệm ra cái này mới là chân lý. :shame:

Bác ơi vậy có nên học Microservices không ạ. Em biết về Git với Docker + Kubernetes + AWS + Google Cloud là đủ chưa ạ.
 
Bác ơi vậy có nên học Microservices không ạ. Em biết về Git với Docker + Kubernetes + AWS + Google Cloud là đủ chưa ạ.
Microservices không sai, vấn đề nằm ở người áp dụng cho nên cứ học tẹt đi.
Git, Docker, K8s... nó là công cụ để giúp bạn triển khai microservices dễ hơn.
AWS, GCP có nhiều managed services giúp bạn nhẹ gánh hơn nữa. Học càng nhiều càng tốt.

Mình giờ dùng IaaS là chính chứ AWS, GCP chả mấy khi dùng nữa do nhu cầu ko tới. Dùng IaaS của Linode/Vultr rẻ hơn nhiều.
 
Bác nào giải thích rõ giúp em cái aggregate là gì trong ddd không? Nếu có ví dụ càng tốt ạ.

via theNEXTvoz for iPhone
Aggregate là một cụm các Entity/Value Object liên quan đến nhau trong 1 tính năng nhất định.
Ở đây mình sẽ phải giải thích thêm một chút về Entity và Value Object.
Ví dụ bạn trả tiền điện, bạn chỉ cần quan tâm là đúng địa chỉ nhà mình và số tiền phải trả. Đó là cái value BẠN quan tâm. Thế nên khi xử lý thông tin, dev có thể tách nhỏ 2 thông tin này (từ entity gốc là Hóa đơn) tạo thành 1 object nhỏ hơn. Object nhỏ này được gọi là Value Object. Một tập hợp gồm Entity gốc (trong aggregate sẽ được gọi là root) và các Value Object như thế được gọi là một Aggregate.
 
Aggregate là một cụm các Entity/Value Object liên quan đến nhau trong 1 tính năng nhất định.
Ở đây mình sẽ phải giải thích thêm một chút về Entity và Value Object.
Ví dụ bạn trả tiền điện, bạn chỉ cần quan tâm là đúng địa chỉ nhà mình và số tiền phải trả. Đó là cái value BẠN quan tâm. Thế nên khi xử lý thông tin, dev có thể tách nhỏ 2 thông tin này (từ entity gốc là Hóa đơn) tạo thành 1 object nhỏ hơn. Object nhỏ này được gọi là Value Object. Một tập hợp gồm Entity gốc (trong aggregate sẽ được gọi là root) và các Value Object như thế được gọi là một Aggregate.
Tiện cái Hoá Đơn này, bác cho em thấy luôn cái Bounded Context được không?
 
Tiện cái Hoá Đơn này, bác cho em thấy luôn cái Bounded Context được không?
Bounded Context là gì đã. Dịch nghĩa thô ra thì nó là Ngữ cảnh giới hạn. Giới hạn ở đây là gì? Là các ngữ cảnh nó biệt lập với nhau và có thể hoàn toàn không liên quan gì đến nhau luôn mặc dù nó là cùng 1 tính năng.
Tức là cùng 1 cái tính năng Xuất hóa đơn như thế, nhưng với mỗi khách hàng lại có một yêu cầu khác nhau về định dạng thông tin và số lượng thông tin trên tờ hóa đơn. (Ví dụ hóa đơn điện của hộ gia đình chỉ cần có địa chỉ nhà và số tiền phải nộp, nhưng hóa đơn điện của cty lại quan tâm đến cả tổng lượng điện tiêu thụ từng ngày, rồi thay đổi so với kỳ trước đó ...)Thế nên phương án là chúng ta tách mỗi cái "yêu cầu" này thành một ngữ cảnh riêng biệt và phát triển cho nó thành một Microservice. Mỗi khách hàng khi tiếp cận đến cái tính năng "xuất hóa đơn" này là họ sẽ làm việc với cái microservice của riêng họ để nhận về cái mẫu mà họ mong muốn.
 
+1 cho bác

Đang làm với 1 hệ thống design ban đầu là module mono. Nhưng sếp mới vào áp dụng giải pháp micro service. Cuối cùng thành 1 mớ hỗ độn, trong khi người cầm key chính maintain vẫn là mình :sad:

Cay hơn là sếp đưa ra giải pháp block vài phút, để 2 service nói chuyện với nhau theo kiểu settimeout. Max ping cho 1 giải pháp bét sô nu sừn.
Có ý chí thì đạp sếp mà lên thôi fen
 
Làm việc với microservices cũng đủ lâu để rút dc nhiều kinh nghiệm đau thương. Giờ ông nào mà cứ đòi microservices là cứ phải debate chán chê, chứng minh value mang lại khi áp dụng microservices mới làm. :shame:

https://scs-architecture.org/ -> Bây giờ mới nghiệm ra cái này mới là chân lý. :shame:
Bên dự án cũ follow chặt cái này. Cơ bản là nó chịu khó refactor, viết lại nhiều lần. Struts, spring rồi angular 1, angular, war thành jar, on premise lên aws... Tách db liên tục
 
Back
Top