thắc mắc Domain Driven Design with CQRS, Event Sourcing, .... ?

Lập Trình Viên Gà

Lập Trình Viên Gà

Senior Member
Chào các thím, e đang tìm hiểu về DDD nhưng không có prj thực tế + chủ đề này abstract quá nên lập topic muốn hỏi các thím.

1. Việc chia Command và Query (CQRS) thực sự có ích trong thực tế không? Em đọc thì bảo khi chia command và query ra rất có lợi, vì chia tách ra thì có thể query dùng db A, command dùng db B. Ngoài ra thì còn có thể tối ưu riêng biệt cho chiều Query và chiều Command nhưng em chưa thấy thuyết phục lắm, bác nào giải thích kĩ hơn lợi ích thực tế sẽ là gì giúp em với.

2. Dùng event sourcing sẽ là lưu history thay đổi của 1 object, rồi từ history đó có thể build được state hiện tại của object => Việc này thì có ích gì? Tại sao không lưu luôn state hiện tại

3. Đối với các project requirement chưa rõ ràng thì có làm được DDD không? Cá nhân em nghĩ là không vì làm DDD phải rất rõ business mới có thể làm được

4. Có khóa học hay course nào giải thích rõ về DDD, CQRS, Event Sourcing không các bác share e với
 
1. Event Sourcing thường hay dùng CQRS là vì nếu bạn query trực tiếp lên event store thì nếu dữ liệu lớn thì sẽ rất là chậm, vì bạn bạn phải tổng hợp lại các event streams. Nên Event Sourcing có cái gọi là Projection để build cho phần Query, và bạn có thể build lên các database tùy ý Postgres, NoSQL.

2. Event Sourcing dùng cái gọi là Event Store (có thể dùng Kafka, Event Store DB) để lưu state của các sự kiện đã diễn ra, và là Single Source Of Truth. Từ những sự kiện này bạn có thể build cái lịch sử state của cái Agrregate.

3. Trong DDD cái khó nhất là phần thiết kế bussiness domain có những tách biệt rõ ràng (bounded context) hay còn gọi là Agrregate. Và những Agrregate này là tổng hợp các entity liên quan. Lưu ý là Aggregate thì luôn phải ở trạng thái valid state.

Trong DDD có 3 phần Application, Domain và Infrastructure. Cái phần Domain thì luôn độc lập không phụ thuộc vào Application và Infrastructure.

Theo kinh nghiệm mình thấy DDD chỉ nên dùng cho những Domain phức tạp. Còn Event Sourcing chỉ nên dùng cho những phần nào chú trọng phần audit chẳng hạn như Kế toán.
 
Sửa lần cuối:
cookiebanana đã nói:
1. Event Sourcing thường hay dùng CQRS là vì nếu bạn query trực tiếp lên event store thì nếu dữ liệu lớn thì sẽ rất là chậm, vì bạn bạn phải tổng hợp lại các event streams. Nên Event Sourcing có cái gọi là Projection để build cho phần Query, và bạn có thể build lên các database tùy ý Postgres, NoSQL.

2. Event Sourcing dùng cái gọi là Event Store (có thể dùng Kafka, Event Store DB) để lưu state của các sự kiện đã diễn ra, và là Single Source Of Truth. Từ những sự kiện này bạn có thể build cái lịch sử state của cái Agrregate.

3. Trong DDD cái khó nhất là phần thiết kế bussiness domain có những tách biệt rõ ràng (bounded context) hay còn gọi là Agrregate. Và những Agrregate này là tổng hợp các entity liên quan. Lưu ý là Aggregate thì luôn phải ở trạng thái valid state.

Trong DDD có 3 phần Application, Domain và Infrastructure. Cái phần Domain thì luôn độc lập không phụ thuộc vào Application và Infrastructure.

Theo kinh nghiệm mình thấy DDD chỉ nên dùng cho những Domain phức tạp. Còn Event Sourcing chỉ nên dùng cho những phần nào chú trọng phần audit chẳng hạn như Kế toán.
Nhấp để mở rộng...
Thím có tài liệu nào đọc k thím
 
Lập Trình Viên Gà đã nói:
Chào các thím, e đang tìm hiểu về DDD nhưng không có prj thực tế + chủ đề này abstract quá nên lập topic muốn hỏi các thím.

1. Việc chia Command và Query (CQRS) thực sự có ích trong thực tế không? Em đọc thì bảo khi chia command và query ra rất có lợi, vì chia tách ra thì có thể query dùng db A, command dùng db B. Ngoài ra thì còn có thể tối ưu riêng biệt cho chiều Query và chiều Command nhưng em chưa thấy thuyết phục lắm, bác nào giải thích kĩ hơn lợi ích thực tế sẽ là gì giúp em với.

2. Dùng event sourcing sẽ là lưu history thay đổi của 1 object, rồi từ history đó có thể build được state hiện tại của object => Việc này thì có ích gì? Tại sao không lưu luôn state hiện tại

3. Đối với các project requirement chưa rõ ràng thì có làm được DDD không? Cá nhân em nghĩ là không vì làm DDD phải rất rõ business mới có thể làm được

4. Có khóa học hay course nào giải thích rõ về DDD, CQRS, Event Sourcing không các bác share e với
Nhấp để mở rộng...
Nghe lạ hoắc. Bác có thể chia sẽ sao biết dc mấy cái này ko?
 
diễn đàn có chức năng tìm kiếm đấy, trc đây có bài về cái này rồi, đừng spam nữa phèn
 
Giải thích cái CQRS nhé, khi hệ thống của thím quá lớn, nhiều CCU thì thím phải có cơ chế DB replication. Khi đó sẽ có 1-2 DB instances (master) dùng để insert/update và 2-3 DB instances (replicate) dùng để query read-only. Khi đó Command có thể chỉ trỏ đến Db master, Query chỉ cần trỏ đến Db replicate.

Sent from Samsung SM-A528B using vozFApp
 
Lập Trình Viên Gà đã nói:
Chào các thím, e đang tìm hiểu về DDD nhưng không có prj thực tế + chủ đề này abstract quá nên lập topic muốn hỏi các thím.

1. Việc chia Command và Query (CQRS) thực sự có ích trong thực tế không? Em đọc thì bảo khi chia command và query ra rất có lợi, vì chia tách ra thì có thể query dùng db A, command dùng db B. Ngoài ra thì còn có thể tối ưu riêng biệt cho chiều Query và chiều Command nhưng em chưa thấy thuyết phục lắm, bác nào giải thích kĩ hơn lợi ích thực tế sẽ là gì giúp em với.

2. Dùng event sourcing sẽ là lưu history thay đổi của 1 object, rồi từ history đó có thể build được state hiện tại của object => Việc này thì có ích gì? Tại sao không lưu luôn state hiện tại

3. Đối với các project requirement chưa rõ ràng thì có làm được DDD không? Cá nhân em nghĩ là không vì làm DDD phải rất rõ business mới có thể làm được

4. Có khóa học hay course nào giải thích rõ về DDD, CQRS, Event Sourcing không các bác share e với
Nhấp để mở rộng...
Mình không rõ tại sao nhiều sách/khoá học gộp CQRS, DDD, Event sourcing lại nhưng 3 cái này mình thấy tương đối tách biệt, mặc dù nó thường có thể dùng kết hợp với nhau.

1. Bạn sẽ thấy rất nhiều ở các hệ thống có chức năng tìm kiếm phức tạp. Ví dụ 1 hệ thống đơn giản cần full text search, thông thường các transactional database không được thiết kế để tối ưu tác vụ này. Giải pháp thường thấy là sẽ replicate data qua elasticsearch. Đây là 1 dạng CQRS đơn giản. Thực tế pattern này dùng rất nhiều trong các hệ thống lớn.

2. Event sourcing nó không capture history event của 1 object, nó thường capture business event, từ biz event mới materialize vào database. Về lợi - hại bạn có thể đọc tài liệu của microsoft, nó đề cập chi tiết hơn https://docs.microsoft.com/en-us/azure/architecture/patterns/event-sourcing

3. Được, bên DDD nó có một kỹ thuật gọi là event storming. Mình cũng chỉ biết về lý thuyết chứ thực tế mình chưa dùng bao giờ.
 
tdat00 đã nói:
Giải thích cái CQRS nhé, khi hệ thống của thím quá lớn, nhiều CCU thì thím phải có cơ chế DB replication. Khi đó sẽ có 1-2 DB instances (master) dùng để insert/update và 2-3 DB instances (replicate) dùng để query read-only. Khi đó Command có thể chỉ trỏ đến Db master, Query chỉ cần trỏ đến Db replicate.

Sent from Samsung SM-A528B using vozFApp
Nhấp để mở rộng...
itachicitus đã nói:
Mình không rõ tại sao nhiều sách/khoá học gộp CQRS, DDD, Event sourcing lại nhưng 3 cái này mình thấy tương đối tách biệt, mặc dù nó thường có thể dùng kết hợp với nhau.

1. Bạn sẽ thấy rất nhiều ở các hệ thống có chức năng tìm kiếm phức tạp. Ví dụ 1 hệ thống đơn giản cần full text search, thông thường các transactional database không được thiết kế để tối ưu tác vụ này. Giải pháp thường thấy là sẽ replicate data qua elasticsearch. Đây là 1 dạng CQRS đơn giản. Thực tế pattern này dùng rất nhiều trong các hệ thống lớn.

2. Event sourcing nó không capture history event của 1 object, nó thường capture business event, từ biz event mới materialize vào database. Về lợi - hại bạn có thể đọc tài liệu của microsoft, nó đề cập chi tiết hơn https://docs.microsoft.com/en-us/azure/architecture/patterns/event-sourcing

3. Được, bên DDD nó có một kỹ thuật gọi là event storming. Mình cũng chỉ biết về lý thuyết chứ thực tế mình chưa dùng bao giờ.
Nhấp để mở rộng...
Vậy tức là cái ý hiểu ban đầu của em đúng nhỉ.
1. Em cũng tưởng tượng là sẽ chia ra 2 DB khác nhau, 1 cái để đọc và 1 cái để ghi :D Có bác nào có code Asp C# ví dụ cho việc dùng 2 database này không :D
 
Lập Trình Viên Gà đã nói:
Vậy tức là cái ý hiểu ban đầu của em đúng nhỉ.
1. Em cũng tưởng tượng là sẽ chia ra 2 DB khác nhau, 1 cái để đọc và 1 cái để ghi :D Có bác nào có code Asp C# ví dụ cho việc dùng 2 database này không :D
Nhấp để mở rộng...
my fen đang nghiên cứu 1 vấn đề rất phức tạp đấy, level senior architect / cto quyết định

ko có code nào cả, nhưng mà ví dụ như này

em làm ngân hàng, có 1 db bên core banking, các giao dịnh hàng này thì insert ở đây, db này ko phải sql

đến tối chạy batch thì export data trong ngày sang 1 cái db oracle

các báo cáo thì lấy data bên oracle

vậy ko có code nào cả
 
Love U So Much đã nói:
my fen đang nghiên cứu 1 vấn đề rất phức tạp đấy, level senior architect / cto quyết định

ko có code nào cả, nhưng mà ví dụ như này

em làm ngân hàng, có 1 db bên core banking, các giao dịnh hàng này thì insert ở đây, db này ko phải sql

đến tối chạy batch thì export data trong ngày sang 1 cái db oracle

các báo cáo thì lấy data bên oracle

vậy ko có code nào cả
Nhấp để mở rộng...
Thảo nào e nghiên cứu mấy cái này đau cả đầu
 
1. CQRS phát huy sức mạnh nhất khi đi với reactive programming => tech lead, SA chọn

2. Có tác dụng, sẽ có dự án cần cái lịch sử, và công nghệ này cũng phát huy mạnh vs reactive programming hoặc stream

3. Ko nên dùng DDD, boilerplate nhiều, trong khi spec mập mờ sẽ khiến domain ko rõ => ko phát huy đc hiệu quả kiến trúc đề ra.

Sent using vozFApp
 
1. Việc chia Command và Query (CQRS) thực sự có ích trong thực tế không? Em đọc thì bảo khi chia command và query ra rất có lợi, vì chia tách ra thì có thể query dùng db A, command dùng db B. Ngoài ra thì còn có thể tối ưu riêng biệt cho chiều Query và chiều Command nhưng em chưa thấy thuyết phục lắm, bác nào giải thích kĩ hơn lợi ích thực tế sẽ là gì giúp em với.

Ví dụ tôi có ứng dụng bán hàng online với các tính năng sau
1a)cho phép khách hàng có thể mua hàng online, khách hàng vào trang web chọn sản phẩm, phương thức thanh toán và tiến hành thanh toán và xem kết quả.
1b) khách hàng có thể xem lịch sử các lần mua hàng trên web
1c) có 1 công cụ nội bộ để bộ phận chăm sóc khách hàng có thể tra cứu lịch sử mua hàng khi có khiếu nại từ khách hàng
Dưới góc độ kinh doanh thì nghiệp vụ 1a) quan trọng và cần tính phản hồi nhanh, sẵn sàng cao hơn 1b và 1c vì nghiệp vụ 1a mang lại doanh thu cho công ty, nếu lỗi thì khách hàng có thể bỏ đi mua ở nơi khác. 1b và 1c nếu có chậm chút thì mức độ ảnh hưởng cũng nhỏ, lỗi thì người dùng có thể thử lại sau đó. Do đó phần logic 1b,1c sẽ tách ra 1 module xử lý và dùng database khác, để người dùng có lỡ query dữ liệu nhiều dẫn đến xử lý chậm thì cũng không ảnh hưởng 1a. Ngoài ra 1b,1c chỉ cần cấp quyền đọc, không có quyền ghi trên dữ liệu, việc này cũng hạn chế rủi ro thay đổi dữ liệu trái phép (do bị hack/bug).
Trong ví dụ trên thì Command tương ứng 1a, Query tương ứng 1b, 1c

2. Dùng event sourcing sẽ là lưu history thay đổi của 1 object, rồi từ history đó có thể build được state hiện tại của object => Việc này thì có ích gì? Tại sao không lưu luôn state hiện tại

Ví dụ đối với 1 số ứng dụng liên quan tiền thì cần dựa trên event source để kiểm tra tính đúng đắn của state hiện tại. Ví dụ tôi có ứng dụng lưu trữ tiền ảo , lúc này mỗi user sẽ có 1 số dư. Muốn kiểm tra tính đúng đắn của số dư hiện tại phải dựa trên lịch sử nạp và tiêu (balance = tổng nạp - tổng tiêu). Việc kiểm tra nhằm đảm bảo tính đúng đắn của số dư hiện tại để phát hiện bất thường như hack/bug
 
Bạn lên github search 2 repo eShopOnWeb và eShopOnContainer rồi đọc code nhé. Một cái là monolithic Clean Architecture + DDD, cái còn lại là microservice. Cả 2 đều do nhân viên microsoft build làm sample.
 
Đầu tiên đi từ vấn đề với những hệ thống lượng ccu cao , request lớn thường hay gặp vấn đề về đọc và ghi dữ liệu vào db ko nhất quán gây ra mất dữ liệu hoặc sai dữ liệu.
Nên nó sinh ra cái event sourcing lưu lại state của các aggregate khi cần status của entity thì nó replay lại toàn bộ event . Đồng thời khi ghi vào event store CDC nó sẽ public qua kafka or message queue nào đó cho service subcrice xử lý tiếp và ghi vào db read . Cụ thể thì có bài toán của bọn tiki áp dụng cho việc đặt đơn hàng đó .life cycle của nó là từ khi user order đến khi thanh toán thành công thì là hết.

Gửi từ Quốc thoại đến từ 3021 bằng vozFApp
 
Bạn phải đăng nhập hoặc đăng ký để trả lời tại đây.

Chủ đề tương tự

potay001
thảo luận [K10s - TUI] Dành cho những người não cá vàng khi vận hành Kubernetes
Trả lời
4
Lượt xem
1K
potay001
potay001
martindelophy
thảo luận [Chia sẻ dự án] Timeline Studio – Trình chỉnh sửa video AI mã nguồn mở chạy ngay trong trình duyệt
Trả lời
6
Lượt xem
1K
hoanganh.pro
hoanganh.pro
QuêTui67
thắc mắc Hỏi về Máy Ảo, Spoofer HWID.
Trả lời
0
Lượt xem
298
QuêTui67
QuêTui67
atomwaffen
TP.HCM: Quét mã QR hiện ra hình bữa ăn bán trú, công ty, nguồn gốc thực phẩm
Trả lời
0
Lượt xem
259
atomwaffen
atomwaffen
hellominhtenngoc
thắc mắc Các nhà tuyển dụng có chấp nhận kinh nghiệm tech tự học không hay bắt buộc phải có kinh nghiệm thực tế?
Trả lời
1
Lượt xem
1K
Saga Pattern
Saga Pattern

Thống kê chủ đề

Ngày tạo
Lập Trình Viên Gà,
Người trả lời cuối
parierk,
Trả lời
60
Lượt xem
15.502

Chia sẻ trang này

Quay lại
Lên đầu trang