Xác nhận tính duy nhất khi sử dụng CQRS và Tìm kiếm sự kiện

Question

Tôi đang cố gắng triển khai cơ sở hạ tầng CQRS của riêng mình với Sourcing Event để tìm hiểu nó tốt hơn. Là một dự án mẫu tôi đang triển khai một công cụ blog, tôi biết nó có thể không hoàn toàn phù hợp nhưng tôi chỉ muốn làm việc trên một cái gì đó thực sự.

Vấn đề tôi đã đến bây giờ là xác thực. Mỗi bài đăng có shortUrl và shortUrl phải là duy nhất, nhưng tôi nên đặt xác thực này trong miền ở đâu? Tôi biết rằng tôi sẽ có xác nhận đó trước khi tôi thậm chí gửi lệnh bằng cách đọc từ cửa hàng đọc của tôi để kiểm tra xem nó có hợp lệ không khi tạo lệnh tạo bài đăng hoặc lệnh cập nhật bài đăng.

Tôi có thể nghĩ đến hai "giải pháp".

1. Có tổng Blog mà tiếp tục theo dõi của tất cả các thiết lập trên blog liên quan và cũng có thể tham chiếu đến tất cả các bài viết. Nhưng vấn đề với điều này trong mắt tôi là tôi phải xử lý thông tin liên lạc giữa các tập hợp trong kịch bản đó cũng như mỗi lần tôi cần xác thực tính duy nhất của shortUrl Tôi cần đọc tất cả các sự kiện từ cửa hàng sự kiện để tạo tất cả các bài đăng và điều đó có vẻ phức tạp. Phương án thứ hai mà tôi có là khi sự kiện được kích hoạt và trình xử lý sự kiện của tôi tạo mô hình đọc kích hoạt một sự kiện url ngắn trùng lặp khi nó nhận thấy rằng nó sẽ có hai url ngắn trỏ đến các bài đăng khác nhau. Có hợp lệ để đọc mô hình để kích hoạt sự kiện khi phát hiện lỗi không?

Có còn lựa chọn thay thế nào khác không. Lưu ý rằng tôi biết rằng tên miền của tôi có thể không phù hợp nhất với cqrs và DDD, nhưng tôi đang làm điều này để tìm hiểu trong một miền nhỏ.

Answer 1

Điều đó tùy thuộc vào 'doanh nghiệp' muốn xảy ra. Nếu bạn muốn khách hàng (tác giả của các lệnh) chịu trách nhiệm chọn một URL ngắn, nó phải có một cửa hàng đọc để xác minh tính duy nhất của nó. Khi người dùng nhập vào một URL ngắn, chế độ xem nên kiểm tra xem URL ngắn có phải là duy nhất không và hiển thị lỗi xác thực nếu không. Bất cứ khi nào một bài đăng được lưu, một sự kiện sẽ xuất bản thông tin được cập nhật (bao gồm cả URL ngắn) để giữ cho cửa hàng đọc được đồng bộ hóa.

Answer 2

Tôi sẽ thực hiện dịch vụ miền chỉ chịu trách nhiệm tạo các ShortURL duy nhất. Bạn có thể sử dụng một DB giao dịch để thực hiện hành vi này. Thông thường dịch vụ này sẽ được sử dụng bởi lệnh xử lý một phần của tổng hợp BlogPost. Nếu có một ShortURL trùng lặp, bạn có thể kích hoạt một DuplicateUrlErrorEvent. Bạn có thể nắm bắt điều này trong giao diện người dùng (nhưng không bao giờ 100%) bằng cách tạo mô hình truy vấn mỏng bằng cùng một nguồn dữ liệu, vì vậy bạn có thể truy vấn xem URL rút gọn có độc đáo hay không trước khi gửi bài đăng (như được mô tả bởi @ RyanR's câu trả lời).

Answer 3

Tôi đã đọc qua các câu trả lời khác nhau về vấn đề này và câu hỏi liên quan.

Quyết định được đưa ra chính xác. Nếu bạn có thể tha thứ và chấp nhận hành vi không hoàn hảo đối với một số mức độ hoạt động, vấn đề của bạn đơn giản hơn nhiều để giải quyết, đặc biệt là dưới sự đảm bảo nhất quán yếu.

Tuy nhiên, nếu bạn muốn nhất quán, bạn nên sử dụng dịch vụ kiên trì có bảo đảm nhất quán mạnh mẽ. Ví dụ: lệnh tạo URL ngắn sẽ xác thực rằng cửa hàng đọc không chứa URL ngắn như vậy và chúng tôi sẽ chỉ cam kết sự kiện của chúng tôi, nếu chúng tôi có thể thực hiện thay đổi cho cửa hàng đọc trước tiên.

Nếu chúng tôi có thể thực hiện thay đổi đối với cửa hàng đọc, chúng tôi đã không vi phạm bất kỳ ràng buộc duy nhất nào (giả sử rằng cửa hàng đọc của bạn thực thi ràng buộc đó) và sau đó chúng tôi có thể tiếp tục.

Tuy nhiên, vì chúng tôi có hai giao dịch không nhất thiết phải trên cùng một cơ sở dữ liệu, chúng tôi có thể không thành công sau lần commit đầu tiên. Điều này là OK bởi vì các hoạt động sẽ như một toàn bộ cũng sẽ thất bại. Cửa hàng đọc sẽ phản ánh trạng thái không nhất quán trong một thời gian nhưng ngay khi chúng tôi sửa chữa tổng hợp cửa hàng đọc sẽ trở lại trạng thái nhất quán.

Là quy trình bảo trì, chúng tôi có thể sửa chữa định kỳ các tập hợp đã bị lỗi tiềm ẩn. Và bạn có thể làm điều này bằng cách giới thiệu một cờ báo lỗi chỉ bị xóa nếu cả hai giao dịch đều thành công.

Có một ví dụ trong đó ngân hàng cho phép người dùng rút tiền quá hạn vì họ có phụ phí để bù lại. Điều này đặt ra câu hỏi bởi vì nó sẽ có vẻ cẩu thả để giải quyết một vấn đề như vậy, thậm chí lười biếng. Một số gọi nó là thông minh. Tôi không biết phải nghĩ gì. Ngân hàng có thể có đủ tiền để trang trải nó, vì vậy họ cũng có thể bỏ qua nó nhưng đó không phải là cách thế giới hiện đang hoạt động. Dù sao, tôi digress.

Từ lập trường chính xác, cửa hàng đọc của chúng tôi có bảo đảm nhất quán mạnh mẽ và chúng tôi sẽ viết dự đoán của mình theo cách không thể thực hiện giao dịch cho cửa hàng đọc nếu số dư được đặt ở giá trị âm. Như vậy điều tồi tệ nhất có thể xảy ra là một khoản phí được khấu trừ từ cửa hàng đọc nhưng hoạt động không bao giờ được cam kết hoàn toàn trong cửa hàng sự kiện. Người dùng sẽ thấy tiền bị thiếu trong tài khoản của họ cho đến khi quy trình bảo trì nhận thấy cờ lỗi và đã chữa lành tài khoản. Điều này tôi nghĩ là một sự thỏa hiệp làm việc.