Tìm nguồn cung ứng sự kiện và sự bền bỉ

Tôi đang đọc về nguồn cung cấp sự kiện và có một câu hỏi liên quan đến sự kiên trì.

Tôi vẫn có thể có một DB với tất cả các thực thể, phải không? Hoặc các sự kiện nên được phát lại mỗi khi ứng dụng được khởi động để có phiên bản mới nhất của mỗi thực thể trong bộ nhớ? Có vẻ như một sự lãng phí trên các hệ thống lớn hơn (như trong một lượng lớn dữ liệu)?

Điểm quan trọng với việc tìm nguồn cung ứng sự kiện là tôi có thể phát lại các sự kiện để đưa vào kho lưu trữ dữ liệu nếu cần? (hoặc phân tích dữ liệu)

Với Nguồn sự kiện, câu hỏi chính là "cuốn sách kỷ lục của bạn là gì".

Nếu cuốn sách kỷ lục của bạn là luồng sự kiện của bạn thì bạn sẽ không gặp vấn đề gì. Nếu sổ ghi chép của bạn là "mô hình thực thể" thì các vấn đề sẽ bắt đầu xảy ra ở mọi nơi. Một phần của điều này là bạn có thể nói "nếu tôi mất mô hình thực thể, tôi có thể xây dựng lại nó từ luồng sự kiện của mình không". Nếu bạn tích cực với câu hỏi này thì Nhật ký sự kiện là sổ ghi chép của bạn.

Cũng cần nhớ rằng hầu hết những người sử dụng nguồn sự kiện đều sử dụng mô hình đọc. Mô hình này được sử dụng để truy vấn dữ liệu. Điều này có nhiều khả năng trông giống như mô hình 1nf hơn là mô hình thực thể 3nf. Họ chỉ phát lại các sự kiện để lấy lại trạng thái tổng hợp để xác định xem có nên cho phép ghi hay không.

Bạn sẽ được hưởng lợi nhiều nhất từ ​​việc tìm nguồn cung ứng sự kiện khi bạn quyết định thay đổi kiến ​​trúc hệ thống của mình. Hướng tới một kiến ​​trúc theo phong cách CQRS kết hợp với DDD sẽ mang lại những lợi ích thực sự của việc tìm nguồn cung ứng sự kiện, ít nhất là theo ý kiến ​​của tôi.

Xây dựng một cửa hàng sự kiện hoạt động tốt trong các hệ thống lớn thực sự không phải là một nhiệm vụ dễ dàng. Phát lại tất cả các dữ liệu có thể rất tốn kém, phụ thuộc rất nhiều vào lượng dữ liệu cần được phát lại. Nhưng có những kỹ thuật có thể giúp bạn với điều này, một trong số đó là khái niệm về ảnh chụp nhanh. Phát lại chỉ được thực hiện từ một điểm nhất định về phía trước. Những lợi thế mà một cửa hàng sự kiện mang lại cho hệ thống của bạn là vô giá. Có tất cả mọi thứ xảy ra trong hệ thống của bạn có thể phát lại, tất cả dữ liệu trong từng khoảnh khắc là một điều tuyệt vời. Hãy suy nghĩ về phân tích, về tái tạo lỗi, về thống kê.

Có rất nhiều cửa hàng sự kiện tuyệt vời, cửa hàng cuối cùng vừa được phát hành vào ngày hôm qua Event Store và nó có vẻ như là một cửa hàng thực sự tốt.

Cơ sở dữ liệu truyền thống có thể được lưu giữ cho phần truy vấn trong hệ thống của bạn để xây dựng DTO với dữ liệu được yêu cầu. Cơ sở dữ liệu này có thể được tổ chức và tối ưu hóa xem xét nhu cầu truy vấn của ứng dụng và khách hàng của bạn.

Tôi đã viết một bài viết chi tiết về những lợi ích và kiến ​​trúc CQRS kết hợp với tìm nguồn cung ứng sự kiện thực sự trông như thế nào. Bạn có thể kiểm tra xem CQRS, Sự kiện Miền và đánh giá DDD .

Tôi vẫn có thể có một DB với tất cả các thực thể, phải không? Hoặc các sự kiện nên được phát lại mỗi khi ứng dụng được khởi động để có phiên bản mới nhất của mỗi thực thể trong bộ nhớ?

Câu trả lời phụ thuộc vào yêu cầu của ứng dụng của bạn. Tôi đã thấy nó được thực hiện cả hai cách.

Một gói phần mềm cực kỳ thành công cho các công ty kế toán nhỏ đọc nhật ký CQRS của nó mỗi khi khởi động. Lượng dữ liệu thô tương đối nhỏ, vì vậy thời gian khởi động chỉ dưới một phút ngay cả trên các máy tính chậm hơn. Họ đã làm CQRS trong hơn một thập kỷ trước khi thực hành trở nên phổ biến. Họ biết rằng họ đang làm điều gì đó tốt khi họ nhận ra rằng họ có thể nâng cấp dữ liệu khách hàng của mình nhiều lần mà không gặp phải rắc rối mà họ thấy với các hệ thống lớn hơn của họ.

Trong các hệ thống có khối lượng dữ liệu và / hoặc hệ thống lớn hơn dựa trên chức năng RDBMS để triển khai phía truy vấn, bạn có cơ sở dữ liệu cho "chế độ xem hiện tại" của dữ liệu có nguồn gốc sự kiện (thậm chí bạn có thể có nhiều chế độ xem như vậy). Ưu điểm của phương pháp này là cho phép bạn xây dựng phía truy vấn bằng các công nghệ quen thuộc.