2010-05-26 31 views
6

Đọc trên CQRS có rất nhiều cuộc trò chuyện về thông báo qua email - tôi tự hỏi nơi để lấy dữ liệu từ đó. Hãy tưởng tượng một senario nơi một người dùng mời những người dùng khác tham dự một sự kiện. Để thông báo cho người dùng rằng anh ấy đã được mời tham dự một sự kiện, anh ấy sẽ được gửi một email.CQRS và thông báo qua email

Các bước cụ thể có thể đi như thế này:

  1. Một lệnh CreateEvent với một bộ sưu tập có liên quan của người sử dụng để mời, được nhận bởi máy chủ.
  2. Một số mới Meeting tổng hợp được tạo và phương thức được gọi là InviteUser cho mỗi người dùng được mời.
  3. Mỗi khi người dùng được mời tham dự sự kiện, sự kiện miền UserWasInvitedToEvent được nêu ra.
  4. Người gửi email thông báo chọn sự kiện miền và gửi email thông báo.

Bây giờ câu hỏi của tôi là: Tôi nên tìm thông tin bao gồm trong email ở đâu?

Giả sử tôi muốn bao gồm mô tả về sự kiện cũng như tên của người dùng. Vì đây là CQRS tôi không thể có được nó thông qua mô hình tên miền của tôi; Tất cả các thuộc tính của các đối tượng miền là riêng tư! Tôi có nên truy vấn bên đọc không? Hoặc có thể chuyển email thông báo sang một dịch vụ khác hoàn toàn?

Trả lời

6

Trong CQRS, bạn đang tách lệnh khỏi phía truy vấn. Bạn sẽ luôn luôn muốn đi đến phía truy vấn để lấy dữ liệu cho một trình xử lý sự kiện đã cho. Cơ sở dữ liệu ghi sẽ là một cơ sở dữ liệu riêng biệt chứa dữ liệu cần thiết để xây dựng các đối tượng miền của bạn và sẽ không được tối ưu hóa cho các lần đọc, nhưng để viết.

  1. Tên miền phải đăng ký và gửi sự kiện EventCreated cho trình xử lý sự kiện/bộ xử lý. Điều này có thể được nâng lên từ hàm tạo của tổng hợp Meeting.
  2. Thành phần xử lý sự kiện sẽ nhận sự kiện EventCreated và cập nhật cơ sở dữ liệu truy vấn với dữ liệu chứa trong sự kiện (ví dụ: Id của sự kiện và tên của sự kiện).
  3. Tên miền có thể đăng ký và gửi sự kiện UserWasInvitedToEvent cho bộ xử lý sự kiện.
  4. Bộ xử lý sự kiện sẽ nhận số UserWasInvitedToEvent và cập nhật cửa hàng truy vấn với mọi dữ liệu báo cáo cần thiết.
  5. Một thành phần xử lý sự kiện khác cũng sẽ nhận sự kiện UserWasInvitedToEvent. Quá trình này có thể có quyền truy cập vào cơ sở dữ liệu truy vấn và kéo tất cả dữ liệu cần thiết để gửi email.

Cơ sở dữ liệu truy vấn không gì hơn cơ sở dữ liệu báo cáo, vì vậy bạn thậm chí có thể có một bảng cụ thể lưu trữ tất cả dữ liệu cần thiết cho email ở một nơi.

Để phối hợp nhiều sự kiện khác nhau thành một trình xử lý đơn lẻ (giả sử các sự kiện có thể được xử lý theo thứ tự khác tại các thời điểm khác nhau), bạn có thể sử dụng khái niệm Saga trong xe buýt nhắn tin của mình. NServiceBus là một ví dụ về xe buýt nhắn tin số supports Saga's. Xem câu hỏi StackOverflow này: NServiceBus Delayed Message Processing.

+0

Thật đáng kinh ngạc có thể tạo ra sự khác biệt bao nhiêu cho một từ. Tôi có nghĩa là để nói truy vấn ofcours bên READ!Tôi biết những điều cơ bản của CQRS :) Dù sao, những gì bạn đang nói là bạn sẽ đi đến cửa hàng truy vấn để dữ liệu đưa vào email? Tôi có thể thấy làm thế nào điều này có thể gây ra một vấn đề, như các cửa hàng truy vấn có thể không nessesery được cập nhật, khi sự kiện UserWasInvitedToEvent đến. Một giải pháp khả thi có thể là thành phần/dịch vụ sẽ lắng nghe các cuộc họp, người dùng và lời mời mới và lưu trữ dữ liệu đó, để có thể gửi lời mời? – t0PPy

+0

Vâng, đó là những gì tôi đã nhận được. Có những thứ như Saga trong một số khung tin nhắn nhất định như NServiceBus cho phép bạn phối hợp nhiều trình xử lý sự kiện không nhất thiết phải đến cùng một thứ tự mỗi lần. Bạn cũng có thể muốn xem xét điều đó. Những hành động này như là một luồng công việc của các loại mà sẽ cho phép bạn chờ đợi trên tất cả các thông tin thích hợp trước khi thực hiện một số hành động. –

+0

Cảm ơn bạn đã trả lời - xin lỗi vì đã không quay lại điều này một thời gian dài trước đây. Tôi thích những gì bạn giải thích, nhưng tôi thấy rằng tôi thích một cách tiếp cận hơi khác: làm phong phú thêm sự kiện. – t0PPy

Các vấn đề liên quan