Jak robicie update z wykorzystaniem event sourcingu, załóżmy taki scenariusz że jest jakiś Produkt i ma tam 5 propercji, no i po stronie frontu gościu może sobie edytować dowolną. Czy robicie tak, że jeden event np ProductUpdated i np taki mechanizm, że dana propercja jest opakowana np w Optional<> i do bazy leca tylko zmienione dane, czy może bardziej konkretniej na każdą edytowaną propercję dany event? Jakie jest dobre podejście?
0
3
W sensie, że masz np. definiowanie produktu i ten produkt ma kilka właściwości (opis, cena, moment w czasie w którym produkt staje się widoczny, jakiś obrazek produktu itp. ), to pytasz, które podejście jest dobre? Czy generować 3 eventy "DescriptionChanged, PriceChanged, ValidFromChanged" vs 1 event "ProductDescriptionChanged"?
O ile nie byłoby jakiegoś uzasadnienia biznesowego, żeby mieć mega rozdrobnienie na te 3 eventy, to osobiście wybrałbym jeden event opisujący zmianę. Wszak, to co się wydarzyło, to zmienił się opis biznesowy produktu. W tym przypadku miałbyś:
- 1 zapis do event stora
- przy odbudowie stanu masz zaaplikowanie 1 eventa, a nie 3
Jeśli byłaby to aplikacja call center, to pewnie sensowniej byłoby mieć większą granulację zdarzeń, tak by być w stanie przeanalizować ile musi się naklikać konsultant, żeby obsłużyć zgłoszenie klienta.
2
Ciekawe zagadnienie, bo event sourcing naprawdę wymusza inne myślenie na wielu warstwach systemu, aż do warstwy UI. Najprościej rzecz ujmując, ES najlepiej pasuje właśnie tam gdzie nie mamy zwykłych operacji CRUD-owych, a stosujemy task-based UI dzięki czemu możemy wyraźnie opisać jaka zmiana zaszła, jednocześnie bez nadmiernego rozdrabniania się na poszczególne pola.