2013-04-27 28 views
7

Tôi đang trong quá trình áp dụng các khái niệm DDD để thiết kế các dự án tiếp theo của chúng tôi, và cụ thể hơn là CQRS.CQRS và các hoạt động đồng bộ (như đăng ký người dùng)

Sau khi đọc rất nhiều nội dung, tôi hiện đang cố gắng triển khai Chứng minh khái niệm đơn giản.

Vấn đề là tôi bị mắc kẹt ngay sau khi tôi bắt đầu: p

Tôi đang cố gắng để áp dụng phương pháp này để một quá trình đăng ký sử dụng đơn giản, nơi bước là:

  • tài lấp đầy đăng ký hình thức & gửi yêu cầu
  • ứng dụng tạo ra người dùng
  • ứng dụng xác thực người dùng (đăng nhập tự động vào)
  • ứng dụng gửi một verifica tion email cho người dùng
  • Ứng dụng chuyển hướng người dùng ở một nơi khác với một thông báo xác nhận

Từ một điểm thực hiện xem, những gì tôi có được cho đến nay là:

  • Hành động điều khiển ánh xạ yêu cầu dữ liệu đến đối tượng RegisterCommand
  • Hành động điều khiển yêu cầu Command Bus xử lý RegisterCommand
  • Phương thức xử lý lệnh (UserService) "đăng ký" tạo đối tượng Người dùng mới (cho dù một lệnh mới hoặc một đối tượng nhà máy)
  • Mô hình này đặt ra một RegisterEvent
  • Việc xử lý lệnh yêu cầu kho để lưu trữ các đối tượng người dùng mới

Vậy đó, các hành động điều khiển không biết về bất kỳ cái đó. Vì vậy, tôi đoán là, vì mọi thứ trong bối cảnh này phải được thực hiện đồng bộ (ngoại trừ gửi email), tôi có thể sử dụng một lệnh lệnh trực tiếp/đồng bộ, và trong hành động điều khiển, ngay sau lệnh gọi bus , Tôi có thể truy vấn cho một người dùng chỉ đọc (cơ sở dữ liệu truy vấn) và nếu nó tồn tại giả định rằng mọi thứ diễn ra tốt đẹp, vì vậy tôi có thể cung cấp cho người dùng một thông báo xác nhận.

Quá trình đăng nhập tự động được xử lý bởi Trình xử lý sự kiện.

Giả sử rằng điều này là chính xác, điều gì sẽ xảy ra nếu xảy ra sự cố, cách thông báo cho người dùng thông tin chính xác?

Ví dụ phổ biến thường được sử dụng trong các bài viết chúng tôi có thể tìm thấy trên internet: Khách hàng thanh toán đơn đặt hàng của mình bằng cách sử dụng thẻ tín dụng đã hết hạn. Hệ thống chấp nhận yêu cầu, thông báo cho người dùng rằng mọi thứ đều ổn, nhưng người dùng nhận được email một vài phút sau đó nói với anh rằng đơn hàng của anh ta không thể được xử lý.

Vâng, kịch bản này có thể chấp nhận được trong nhiều trường hợp, nhưng đối với một số trường hợp khác, điều đó là không thể. Vậy các ví dụ giải quyết những trường hợp sử dụng này ở đâu? : p

Cảm ơn bạn!

+0

các bộ xử lý này có đang chạy trong cùng một chuỗi không? hoặc bạn có một dịch vụ khác đang chạy ở nơi khác xử lý các lệnh/sự kiện? – Sarmaad

+0

Chúng tôi sử dụng ngôn ngữ kịch bản, do đó không có chuỗi. Một máy chủ xếp hàng cuối cùng có thể tồn tại, nhưng không phải cho trường hợp sử dụng này tôi nghĩ. – Benjamin

Trả lời

1

Vấn đề với các ví dụ giả tạo là bạn có thể thay đổi ý định về chức năng "miền", do đó, ít sử dụng trong việc thảo luận về ví dụ này nói riêng. Tiền đề cơ bản mà bạn dường như đã từ bỏ là chúng ta phải giả định rằng mọi thứ sẽ chỉ hoạt động. Mọi thứ khác là về rủi ro và giảm thiểu nó. Lấy ví dụ này, nếu tôi hỏi bạn, nếu tôi mất 1 đăng ký người dùng trong 100000 thì sao? Nếu tôi mất 1 trong số 10 thì sao? Tại sao điều đó lại xảy ra? Tôi có vấn đề lớn hơn vào thời điểm đó không? Người dùng tương lai có thể đăng ký lại khi hệ thống trở lại trực tuyến và hoạt động như mong đợi không? Khi nào vậy? Điều gì sẽ xảy ra nếu chúng tôi giám sát chất lượng dịch vụ của mình và ngăn người dùng đăng ký vì chúng tôi không thể đảm bảo chất lượng họ đã liên kết với thương hiệu của chúng tôi? Điều gì sẽ xảy ra nếu máy chủ phát nổ hoặc trung tâm dữ liệu bị nuked? Chúng ta có muốn bảo vệ chống lại điều đó không? Bạn thấy đấy, không có câu trả lời đúng. Chỉ có các sắc thái khác nhau của màu xám. Vậy làm cách nào để giảm thiểu rủi ro? Chúng tôi có thể làm cho mọi thứ đồng bộ nhưng đó chỉ là sự bảo đảm tại thời điểm hạn chế đó. Điều gì sẽ xảy ra nếu tôi phải khôi phục bản sao lưu cũ 2 giờ (ví dụ: vì đĩa bị hỏng)? Đó là 2 giờ người dùng đã đăng ký bị mất (có thể). Những điều này xảy ra ... Tôi chỉ muốn chỉ ra thuyết tương đối của những gì tôi coi là một cảm giác an toàn sai lầm. Giảm thiểu nó, đầu tư vào những gì bạn không thể đủ khả năng để mất, chắc chắn rằng bạn có một đường mòn kiểm toán tốt. Có lẽ không phải là câu trả lời bạn đang tìm kiếm ...

+0

Tôi ổn với tất cả các khía cạnh của "sự nhất quán cuối cùng" mà cuối cùng không thực sự là một vấn đề kể từ khi bạn đề cập đến chúng tôi phải chấp nhận rằng "mọi thứ chỉ đi làm" 99,99% thời gian. Nhưng trong một số trường hợp, từ quan điểm trải nghiệm người dùng, tôi phải cho phép người dùng sử dụng dịch vụ ngay sau khi anh ấy gửi yêu cầu đăng ký của mình, nhưng sau đó thì sao? Tôi phải để anh ta gửi một loạt các lệnh, như tạo nội dung, bằng cách chỉ dựa vào những gì khách hàng giả định về dữ liệu người dùng? Ý tôi là, ủy quyền người dùng là một chủ đề hợp lý chẳng hạn. – Benjamin

+0

Không, bạn hoàn tất quá trình đăng ký. Sau đó, bạn tiếp tục. Dễ dàng. Bạn muốn cung cấp UX tốt hơn? Tại sao không cho phép người dùng tiếp tục với tư cách là người dùng tạm thời (cho đến khi người dùng xác nhận đăng ký) và ngầm kết hợp điều đó với tài khoản người dùng đã đăng ký của mình? Hoặc chỉ cần cập nhật mô hình đọc cho trường hợp sử dụng cụ thể này đồng bộ? Rất nhiều lựa chọn, IYAM. –

3

Tôi nghĩ trường hợp sử dụng đăng ký này gần hơn với việc thanh toán cho trường hợp sử dụng đơn hàng hơn bạn nghĩ.

Hầu hết các nhà lãnh đạo tư tưởng CQRS đề xuất xác thực trên mặt đọc trước khi đưa ra một lệnh, do đó cho lệnh của bạn xác suất thành công cao hơn.

Nếu xác thực không thành công ở phía bên đọc, bạn biết cách xử lý việc này - làm cho người dùng chọn một tên khác trước khi bạn thậm chí gửi lệnh đăng ký. Nếu xác thực thành công, hãy gửi lệnh - bây giờ bạn đang nói có thể là vài trăm micro giây AT MOST nơi người dùng khác có thể vào và lấy cùng tên người dùng giữa thời gian bạn đã xác thực lệnh và gửi nó đi. Bất thường.

Và trong trường hợp rất hiếm khi xảy ra, bạn thực hiện giống như ví dụ thẻ tín dụng đã hết hạn - lần tiếp theo người dùng đăng nhập, bạn trình bày giải thích và biểu mẫu mới tên người dùng - hoặc gửi cho họ email có nội dung "hey - ai đó có tên người dùng đó, vui lòng nhấp vào đây để chọn tên người dùng mới". Tại sao điều này hoạt động? Vì bạn có một ID duy nhất cho người dùng đó.

Xem trang đăng ký người dùng như Twitter. Ngay sau khi bạn nhập tên người dùng, nó thực hiện một cuộc gọi Ajax nhỏ và nói "không, điều này được thực hiện" hoặc "cái này tốt!" Đó là xác thực trước.

Tôi hy vọng điều này sẽ hữu ích!

+0

Vâng, tôi đồng ý với kịch bản bạn mô tả.Vấn đề là trong quá trình đăng ký, không ai muốn người dùng đợi máy chủ xử lý yêu cầu. Bạn không thể chỉ giả mạo nó, như bạn sẽ khi người dùng thêm một bình luận ví dụ, bằng cách ngay lập tức hiển thị thông điệp của mình với javascript. Thông thường, người dùng có thể sử dụng dịch vụ ngay lập tức. Chúng tôi cũng có thể hình dung quy trình đăng ký 3 bước: 1. Người dùng nhập tên người dùng/email/mật khẩu 2. Người dùng được tự động đăng nhập và được mời hoàn thành hồ sơ của mình 3. Người dùng được chuyển hướng đến trang chủ của mình (cho dù là một nguồn cấp dữ liệu hoặc bất cứ điều gì khác) – Benjamin

+0

Tôi nghĩ rằng nó sẽ là OK. Miễn là bạn không sử dụng tên người dùng làm ID (thay vì sử dụng ID thay thế - GUID hoặc thứ gì đó), người dùng có thể đăng nhập và được đưa tới trang chủ của mình vì họ sẽ sử dụng ID thay thế để đưa ra quyết định, chứ không phải tên người dùng. – Dan

+0

Điều này có ý nghĩa về mặt lý thuyết, nhưng trong bối cảnh thực tế, điều này sẽ không đủ. Nếu người dùng được chuyển hướng sau khi đăng ký, anh ta hy vọng có thể bắt đầu sử dụng dịch vụ. Bạn không thể nói một cách hợp lý rằng anh ta phải chờ đợi để làm bất cứ điều gì, điều này sẽ là một trải nghiệm người dùng khủng khiếp. Trên trang chủ, bạn có thể muốn hiển thị nhiều thông tin hơn chỉ là ID người dùng và chắc chắn bạn không muốn người dùng thực hiện bất kỳ thao tác nào mà không chắc chắn rằng mình đã được xác thực hoàn toàn trong hệ thống và dữ liệu giao diện người dùng không đủ để đảm bảo điều đó. – Benjamin

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