Wątek przeniesiony 2017-06-13 16:30 z Nietuzinkowe tematy przez somekind.

DDD + CQRS + Event Sourcing - wyświetlanie danych po dodaniu/modyfikacji/usunięciu ?

0

Mamy przykładowo listę książek - dodajemy nową książkę więc rzucana jest komenda CreateBookCommand, przechwytywana przez CreateBookCommandHandler, następnie rzucany jest event BookCreatedEvent, zapisywany w bazie do zapisu eventów i przechwytywany przez BookCreatedEventHandler, który zapisuje nową książkę do bazy do odczytu.

No i zdarza się, że po dodaniu książki jak jest się przekierowywanym z powrotem na listę książek to EventHandler nie zdążył jeszcze zapisać tej książki do bazy do odczytu więc użytkownik nie widzi książki, którą dodał przed chwilą. Jak jest rozwiązywany ten problem w podejściu CQRS + Event Sourcing, bo zakładam, że jest to powszechny problem?

3

A trzeba to rozwiazywac? Jesli wracasz na liste ksiazek to tego nie rozwiazesz - ksiazka pojawi sie za jakis czas i tyle. Mozesz oczywiscie informowac uzytkownikow ze baza sie zmienila i aby ja odswiezyli - ale nie o to Ci chyba chodzi. Wybrane przez Ciebie rozwiazanie tak sie zachowuje (eventual consistency - nie wiem jak to jest po naszemu) - jesli bardzo Ci to przeszkadza to serwer z odpowiedzia bedzie musial czekac na potwierdzenie zapisu - a tego raczej nie chcesz robic. Ewentualnie po dodaniu ksiazki przenosc uzytkownika na strone z detalami utworzonej pozycji (jesli pozycja nie zostala jeszcze utworzona to informacja ze jest w trakcie procesowania i automatyczny reload co 10 sek).

0

Znalazłem artykuł, który opisuje ten problem i zawiera również to co napisałeś @tamtamtu:
http://danielwhittaker.me/2014/10/27/4-ways-handle-eventual-consistency-ui/

Jest to bez wątpienia duża wada tej architektury, bo użytkownicy są przyzwyczajeni do tego, że to co zrobią jest widoczne natychmiast i możemy albo starać się przekonać użytkowników, że zmiany zobaczą dopiero za jakiś czas, albo stosować kombinacje alpejskie w stylu fakowych danych czy użycia SignalR.

0
wiewiorek napisał(a):

użytkownicy są przyzwyczajeni do tego, że to co zrobią jest widoczne natychmiast

Tego oczekuje użytkownik i to powinien dostarczać dobry interfejs, niemniej nie wiem, czy są do tego przyzwyczajeni. Jest wiele aplikacji na poziomie "enterprise", które nie oferują takiego poziomu spójności. Choćby BZ WBK nie uaktualniał jeszcze jakiś czas temu salda od razu po zleceniu operacji (i chyba dalej ma z tym problem), mbank od początku nie miał natomiast z tym trudności.

Event ma u Ciebie jakiś guid i możliwość sprawdzenia stanu asynchronicznie? Można to rozwiązać np. podobnie do requestu o wygenerowanie dokumentu - cyklicznie sprawdzamy stan i update rzędu tabeli.

1 użytkowników online, w tym zalogowanych: 0, gości: 1