MidKỹ thuậtĐánh đổi kiến trúc
Khi nào event sourcing đáng để đánh đổi độ phức tạp?
Thử trả lời trước
Đáp án mẫu
Với event sourcing, bạn không lưu trạng thái hiện tại. Bạn lưu một chuỗi sự kiện chỉ-thêm, như OrderPlaced và ItemAdded, và suy ra trạng thái bằng cách phát lại chúng. Các mô hình đọc thường được xây riêng, thường kết hợp CQRS.
Nó đáng giá khi:
- bạn cần dấu vết kiểm toán đầy đủ và đáng tin cậy, như trong tài chính hoặc tuân thủ,
- bản thân lịch sử có giá trị: truy vấn theo thời gian, "tháng trước nó trông thế nào", hoặc gỡ lỗi bằng phát lại,
- bạn cần dựng mô hình đọc hoặc projection mới từ dữ liệu quá khứ,
- miền nghiệp vụ vốn hướng sự kiện và phức tạp.
Chi phí là có thật: một cách tư duy khác, quản lý phiên bản schema sự kiện, mô hình đọc nhất quán cuối cùng, snapshot cho chuỗi dài, truy vấn tuỳ ý khó hơn, và khó xoá dữ liệu để đáp ứng quy định riêng tư, cần các kỹ thuật như crypto-shredding.
Với CRUD thông thường, một database bình thường kèm bảng audit đơn giản hơn. Tôi chỉ áp dụng event sourcing cho những phần của hệ thống được hưởng lợi, không phải ở mọi nơi.
Ý chính
- Trạng thái được suy ra từ nhật ký sự kiện chỉ-thêm
- Đáng dùng cho kiểm toán, lịch sử và projection mới
- Chi phí: tiến hoá schema, nhất quán cuối cùng, truy vấn, xoá dữ liệu
Câu hỏi nối tiếp thường gặp
- Bạn tiến hoá schema sự kiện sau khi đã lưu sự kiện thế nào?
- CQRS liên quan đến event sourcing như thế nào?
Lỗi thường gặp
- Áp dụng event sourcing cho các miền CRUD đơn giản
- Nhầm event sourcing với việc chỉ phát sự kiện lên message broker