Read model
Last updated
Was this helpful?
Last updated
Was this helpful?
Wyświetlanie danych z wielu agregatów na jednym widoku
Raporty
Wyszukiwanie
Wprowadzanie zmian w widokach
RODO
Jeśli mamy jeden agregat, nie pojawia się nam problemy, związane z wydajnością, gdy ilość eventów nie jest zbyt duża. Pozbywamy się modeli i persystencji ORMowej, zapis działa na dokumentach, więc działa stosunkowo szybko.
Nie dużo odczytu, ale dużo zapisu w różnych miejscach.
Może być to anti-pattern, jednak to co poświęcamy to latencja przy zapisie. Decyzja podjęta świadomie upraszcza nam sprawy związane z późniejszym odczytem.
Gdy odczyt jest naprawdę duży.
Sugeruje się wykorzystanie osobnej bazy danych i evetual cosistency.
Wiele zapytań o poszczególne agregaty.
To co można zrobić, to dodanie obsługi wielu zapytań requestowych zwracanych jako jedno API po stronie serwera na frontendzie.
Monolityczny UI
Mikrofrontendy
Wrażliwe dane w jednym agregacie - odpowiedzialność za dane wrażliwe jest w osobnym miejscu które możemy usunąć
Usuwanie strumienia - eventy są niemutowalne, ale strumień danych można już edytować
W przypadku wydarzeń publicznych:
Dane są zreplikowane w wielu miejscach
Każdy moduł odczytowy musi realizować prawo do zapomnienia
Usuwanie strumienia
W przypadku raportów mamy problem wydajnościowy.
W takiej sytuacji można stworzyć publiczny read-model.
Nie zawsze należy udostępniać wydarzenia do read-modelu.
Np. jeśli mamy program do edycji tekstu, wydarzeniem prywatnym będzie edycja pogrubienia, kursywy czy dodania tekstu, ale wydarzeniem publicznym (dla read-modelu), będzie już jego modyfikacja.
Outbox
Mogą być wzbogacane
Globalna kolejność musi być istotna
Mogą być przetwarzane w różnym tempie
Ktoś inny zapisuje, ktoś inny odczytuje
Przekazanie zlecenia
Czytanie własnych zapisów
Na bazie zwróconego sukcesu
Na bazie zwróconego zdarzenia
Spowalnianie użytkownika
Strona z potwierdzeniem albo podsumowaniem
Wydłużenie przetwarzania komendy
Odczyt może być spójny, ale płacimy latencją
Lokalne modele odczytowe + kompozytowy UI może rozwiązywać problemy
Agregowane modele odczytowe i zdarzenia publiczne są rozwiązaniem, ale tylko wtedy gdy faktycznie mamy problem z dużą ilością danych. Nie powinny one jednak używać wewnętrznych wydarzeń, tylko swoich własnych - publicznych.
