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

EDAU_SG · 29/6/23

Em cũng đang build 1 hệ thống dùng CQRS với Kafka
Em thắc mắc tí là đối với hệ thống sử dụng EDA thì bắt buộc phải có Even Store không?

disconnect · 29/6/23

Làm DDD giúp phân tách phần design hệ thống, như dự án mình ông TL làm DDD sau đó bên dev sẽ implement. Tránh mỗi ông implement 1 kiểu trong hệ thống.

Darabeny · 30/6/23

voz6366 đã nói:
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.

Bác giải thích kỹ hơn đoạn này được không. Ở trường hợp này sẽ dính 1 chỗ đó là việc read từ db replica sẽ có độ trễ nhất định so với việc write của db master. Vậy thì sẽ có thể gây ra race condition.
Ví dụ như trong life cycle trên, khi user cùng đặt đơn hàng thì làm sao để đảm bảo không bị race condition này bác.
Vấn đề này thì Tiki xử lý như thế nào bác?

LoserThapNghiep · 30/6/23

Topic hay. Chấm hóng.

billy_don · 30/6/23

Darabeny đã nói:
Bác giải thích kỹ hơn đoạn này được không. Ở trường hợp này sẽ dính 1 chỗ đó là việc read từ db replica sẽ có độ trễ nhất định so với việc write của db master. Vậy thì sẽ có thể gây ra race condition.
Ví dụ như trong life cycle trên, khi user cùng đặt đơn hàng thì làm sao để đảm bảo không bị race condition này bác.
Vấn đề này thì Tiki xử lý như thế nào bác?

Đặt đơn hàng thì query thẳng vào master luôn rồi xử lý như bình thường bác. Chỉ khi nào thuần read mới query đến replication.

Darabeny · 30/6/23

billy_don đã nói:
Đặt đơn hàng thì query thẳng vào master luôn rồi xử lý như bình thường bác. Chỉ khi nào thuần read mới query đến replication.

Tức là business quan trọng và validate thì vẫn query trên master còn thuần read thì mới dùng replica để giảm tải đúng không bác?
Và query để apply hết luồng của event sourcing rồi mới validate nhưng vẫn đảm bảo tốc độ à?

billy_don · 30/6/23

Darabeny đã nói:
Tức là business quan trọng và validate thì vẫn query trên master còn thuần read thì mới dùng replica để giảm tải đúng không bác?
Và query để apply hết luồng của event sourcing rồi mới validate nhưng vẫn đảm bảo tốc độ à?

Câu hỏi sau mình chưa hiểu lắm, query thì mình cho nó vào layer infrastructure (data access), còn validate thì được thực thi trong domain service.

Mình đoán chắc validate của bạn là hỏi về race condition, như mình làm thì sẽ kéo vào application service để xử lý.

Darabeny · 30/6/23

billy_don đã nói:
Câu hỏi sau mình chưa hiểu lắm, query thì mình cho nó vào layer infrastructure (data access), còn validate thì được thực thi trong domain service.

Mình đoán chắc validate của bạn là hỏi về race condition, như mình làm thì sẽ kéo vào application service để xử lý.

Đúng bác, em nói về race condition. Ý em là việc validate để tránh race condition mà liên quan đến db event sourcing thì chấp nhận việc "hơi chậm" để apply hết luồng sourcing hay sẽ xử lý như thế nào bác.
Ví dụ cụ thể thì như life cycle kia:
- Em tạm hiểu thì Tiki sẽ thiết kế order theo kiểu event-sourcing.
Khi 2 user cùng mua 1 sản phẩm A. Thì để đảm bảo race condition. Khi gọi từ master thì phải apply hết luồng sourcing của order ấy để tính ra số lượng đã bán. Thì mới validate được. Tạm bỏ qua lock các thứ liên quan khác,...
Vậy thì Tiki sẽ chấp nhận mức "hơi chậm" để apply hết luồng sourcing này cho mỗi lần validate hay sao bác

kulboy_vn · 7/7/23

Darabeny đã nói:
Đúng bác, em nói về race condition. Ý em là việc validate để tránh race condition mà liên quan đến db event sourcing thì chấp nhận việc "hơi chậm" để apply hết luồng sourcing hay sẽ xử lý như thế nào bác.
Ví dụ cụ thể thì như life cycle kia:
- Em tạm hiểu thì Tiki sẽ thiết kế order theo kiểu event-sourcing.
Khi 2 user cùng mua 1 sản phẩm A. Thì để đảm bảo race condition. Khi gọi từ master thì phải apply hết luồng sourcing của order ấy để tính ra số lượng đã bán. Thì mới validate được. Tạm bỏ qua lock các thứ liên quan khác,...
Vậy thì Tiki sẽ chấp nhận mức "hơi chậm" để apply hết luồng sourcing này cho mỗi lần validate hay sao bác

Mình cũng đang tìm hiểu về mô hình này. Mà cũng ù ù cạc cạc khó hiểu quá.
Với ví dụ của tiki thì có a tech lead chia sẻ nè

Gửi từ Xiaomi 2211133C bằng vozFApp

Darabeny · 8/7/23

kulboy_vn đã nói:
Mình cũng đang tìm hiểu về mô hình này. Mà cũng ù ù cạc cạc khó hiểu quá.
Với ví dụ của tiki thì có a tech lead chia sẻ nè

Gửi từ Xiaomi 2211133C bằng vozFApp

Oke thank bác. Có confirm như này thì cơ bản là em vẫn đang hiểu đúng cái solution của Tiki đang áp dụng này.
Nếu như bác muốn tìm hiểu thì em nghĩ là bác nên chia nhỏ các khái niệm ra trước.

Em nghĩ là bác nên tìm riêng lẻ từng khái niệm ra thì nó sẽ rõ ràng hơn, chứ gộp vào thì các bài viết thường nó sẽ bị chung chung, không đi vào chi tiết được.

Symbiosis · 8/7/23

EDAU_SG đã nói:
Em cũng đang build 1 hệ thống dùng CQRS với Kafka
Em thắc mắc tí là đối với hệ thống sử dụng EDA thì bắt buộc phải có Even Store không?

Ý bạn là dùng Event Sourcing? Không nhất thiết, nếu đặc thù business không cần, thì dùng PubSub đơn giản vẫn hiệu quả.

Darabeny đã nói:
- Em tạm hiểu thì Tiki sẽ thiết kế order theo kiểu event-sourcing.
Khi 2 user cùng mua 1 sản phẩm A. Thì để đảm bảo race condition. Khi gọi từ master thì phải apply hết luồng sourcing của order ấy để tính ra số lượng đã bán. Thì mới validate được. Tạm bỏ qua lock các thứ liên quan khác,...
Vậy thì Tiki sẽ chấp nhận mức "hơi chậm" để apply hết luồng sourcing này cho mỗi lần validate hay sao bác

Tui không biết Tiki, nhưng thông thường thì để tối ưu performance, hệ thống sẽ lưu snapshot của một aggregate lại một thời điểm rồi apply những events từ sau thời điểm đó đến hiện tại nên có thể tránh chuyện bị "hơi chậm" như bạn nói.

Darabeny · 9/7/23

Symbiosis đã nói:
Tui không biết Tiki, nhưng thông thường thì để tối ưu performance, hệ thống sẽ lưu snapshot của một aggregate lại một thời điểm rồi apply những events từ sau thời điểm đó đến hiện tại nên có thể tránh chuyện bị "hơi chậm" như bạn nói.

Thường thì đoạn snapshot này của aggregate sẽ lưu lại rồi xóa những event trước đó. Hay vẫn sẽ được giữ nguyên và chỉ đánh dấu đến id event đã xử lý thôi thế bác?

Symbiosis · 9/7/23

Darabeny đã nói:
Thường thì đoạn snapshot này của aggregate sẽ lưu lại rồi xóa những event trước đó. Hay vẫn sẽ được giữ nguyên và chỉ đánh dấu đến id event đã xử lý thôi thế bác?

Về nguyên tắc là không được xóa nha bạn, tất cả những events đều là immutable và phải giữ lại để có thể truy xuất lịch sử và tái hiện khi cần (thường là khi auditing), đó chính là lợi điểm lớn nhất của Event Sourcing.

Việc lưu các snapshots cơ bản chỉ là kỹ thuật caching để tránh bị regression thôi. Events vẫn là source of truth, chứ không phải snapshots.

snake_case · 9/7/23

Thím nào giải thích giúp em việc tại sao các bank thường sử dụng event sourcing? nó có an toàn hơn cơ sở dữ liệu truyền thống không, e.g. mất điện, server sự cố, etc.?

RPG29 · 9/7/23

snake_case đã nói:
Thím nào giải thích giúp em việc tại sao các bank thường sử dụng event sourcing? nó có an toàn hơn cơ sở dữ liệu truyền thống không, e.g. mất điện, server sự cố, etc.?

Event Sourcing là pattern thôi, ko liên quan gì db (tất nhiên có db dc build riêng cho application dạng này). Lợi ích tuyệt đối của nó là auditable, có thể truy ngược lại lịch sử để kiểm toán thông tin.

Bản chất nó là dạng append only log, các log này không bao giờ bị xóa. Muốn tái hiện lịch sử thì chỉ cần chạy lại log là xong.

Có thể lấy Git làm ví dụ, chính là một dạng db lưu log mỗi lần commit.
Một dạng nữa là cái sổ kế toán cứ phát sinh giao dịch là ghi vào đấy.

Còn lịch sử của cái việc dùng pattern này có lẽ chính là do nghiệp vụ kế toán ấy. Phải lưu trữ lại từng giao dịch. Với hồi xưa hay lưu trữ dữ liệu bằng băng từ nên lại càng phù hợp.

venom25 · 9/7/23

An aggregate root is the entity that acts as the entry point for accessing and modifying the aggregate. It is responsible for enforcing the business rules and invariants of the aggregate. An aggregate root may have child entities or value objects that are part of the same aggregate, and they can only be accessed through the aggregate root. When you load an aggregate root from a repository, you should load the entire aggregate, including the parent and child data. This way, you can ensure that the aggregate is always in a consistent and valid state.

Cho mình hỏi định nghĩa của Aggregate Root trong DDD là như này. Nếu như theo định nghĩa, với ví dụ trong Case-Activity Management System. Khi load data Case của 1 user, theo đúng định nghĩa của DDD về Aggrerate Root, thì mình phải load toàn bộ Case - Activities, Activity Types lên từ database. Vậy chẳng lẽ cái này bị N + 1 khi dùng ORM???

cba · 9/7/23

Không rõ cái MariaDB chịu được bao nhiêu/s CCU nhỉ? Cứ cho là CPU 16 core đi

Liquidation75 · 9/7/23

Đá lên hóng cao nhân

Sent from Google Pixel 6 Pro using vozFApp

Raiha173 · 9/7/23

venom25 đã nói:
Cho mình hỏi định nghĩa của Aggregate Root trong DDD là như này. Nếu như theo định nghĩa, với ví dụ trong Case-Activity Management System. Khi load data Case của 1 user, theo đúng định nghĩa của DDD về Aggrerate Root, thì mình phải load toàn bộ Case - Activities, Activity Types lên từ database. Vậy chẳng lẽ cái này bị N + 1 khi dùng ORM???

Thế nên người ta hay nói CQRS+ES chung là vậy. Mặc dù nó là 2 thứ riêng biệt.
Case của bạn sẽ build read model phù hợp với biz bạn cần

Darabeny · 10/7/23

Symbiosis đã nói:
Về nguyên tắc là không được xóa nha bạn, tất cả những events đều là immutable và phải giữ lại để có thể truy xuất lịch sử và tái hiện khi cần (thường là khi auditing), đó chính là lợi điểm lớn nhất của Event Sourcing.

Việc lưu các snapshots cơ bản chỉ là kỹ thuật caching để tránh bị regression thôi. Events vẫn là source of truth, chứ không phải snapshots.

Thankiu bác nhiều. Mấy vấn đề này em có search cũng như hỏi khá nhiều nơi giờ mới được bác giải đáp

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

Junior Member

Junior Member

Junior Member

Member

Senior Member

Junior Member

Senior Member

Junior Member

Senior Member

Junior Member

Senior Member

Junior Member

Senior Member

Senior Member

Đã tốn tiền

Senior Member

Member

Member

Member

Junior Member

Chủ đề tương tự

Thống kê chủ đề

Chia sẻ trang này