Gotowe rozwiązania na największe problemy z Event Sourcingiem

pytanie zadane 29 lutego w Algorytmy przez migatotech Początkujący (390 p.)

Cześć, chciałem podzielić się z wami nowym filmem na temat event sourcingu. Czy obudził was kiedyś telefon w środku nocy podczas dyżuru na on-callu, bo jakiś problem się pojawił w systemie? W tym filmie omawiam produkcyjne problemy i daję gotowe rozwiązania. Czy macie podobne przemyślenia? A może do niektórych problemów byście podeszli jeszcze inaczej? Zachęcam do komentowania
https://youtu.be/jZiPCUl2-tk

komentarz 29 lutego przez tkz Nałogowiec (42,000 p.)

Nie trzymanie danych != zaszyfrowane dane bez klucza. "Tracisz" dostęp, ale nie dane. W 4 punkcie podałeś definicje CQS, nie CQRS. Co do 3 punktu również mam obiekcje. Handler do każdej wersji nie jest konieczny zawsze. Kwestia wymagań. Poza tym należy odróżnić zwykłą zmianę, a tzw. breaking change.

komentarz 29 lutego przez migatotech Początkujący (390 p.)

CQR rozdzielenie zapisu od odczytu, CQRS oddzielenie odpowiedzialności kodu odpowiadającego za zapis i odczyt - mówiąc o snapshocie i read modelu jako przykładu command i query uważam, że dałem poprawną definicję CQRS.

Kwestia wymagań, zgadza się, ale wszystko jest tego kwestią. Jeśli jednak nie będziesz miał handlera do każdej wersji, to w jaki sposób będziesz w stanie określić stan systemu w momencie X?

Tak, tracisz dostęp do danych, a jaki jest z tym problem? :)

komentarz 29 lutego przez tkz Nałogowiec (42,000 p.)

CQR rozdzielenie zapisu od odczytu, CQRS oddzielenie odpowiedzialności kodu odpowiadającego za zapis i odczyt - mówiąc o snapshocie i read modelu jako przykładu command i query uważam, że dałem poprawną definicję CQRS.

CQRS jest w(bardzo w skrócie) kontekście systemu, z tego co mówiłeś narzuciło mi się CQS bo wspomniałeś o operacjach, a nie całym flow.

Kwestia wymagań, zgadza się, ale wszystko jest tego kwestią. Jeśli jednak nie będziesz miał handlera do każdej wersji, to w jaki sposób będziesz w stanie określić stan systemu w momencie X?

Zdecydowanie i wtedy mamy innego odbiorcę. Jeżeli roibsz coś dla szerokiej publiki z poza domeny, trzymasz się ogólnych zasad, bo takie po prostu obowiązują. Nie potrzebujesz zawsze określać stanu X. Kwestia wymagań, warto po prostu o tym wspominać.

Tak, tracisz dostęp do danych, a jaki jest z tym problem? :)

Dla mnie? Żaden. Dla ludzi którzy mi płacą? Ogromny. Brak dostępu nie jest równy nie przetrzymywaniu danych.

komentarz 29 lutego przez migatotech Początkujący (390 p.)

Dla mnie? Żaden. Dla ludzi którzy mi płacą? Ogromny. Brak dostępu nie jest równy nie przetrzymywaniu danych.

Próbuję jeszcze to zrozumieć - chodzi Ci o to, że przechowywanie danych kosztuje, czy o to że jest to niezgodne z ustawą o RODO? Bo decydując się na event sourcing automatycznie decydujemy się na duże ilości danych, bo jest to zgodne z decyzją biznesową na bazie której ten wzorzec został wybrany do implementacji. W kontekście RODO wymagania są spełnione.

komentarz 29 lutego przez tkz Nałogowiec (42,000 p.)

W kontekście RODO wymagania są spełnione.

Podaj mi proszę artykuł RODO, który mówi wprost, że dane NIE MUSZĄ zostać usunięte, a wystarczy "utracić" dostęp jak to ująłeś w nagraniu. Proszę zwróć uwagę, że cały czas usunięte != nie możesz ich odszyfrować w sposób prosty/szybki.

Bo decydując się na event sourcing automatycznie decydujemy się na duże ilości danych, bo jest to zgodne z decyzją biznesową na bazie której ten wzorzec został wybrany do implementacji.

Śmiała teza, że decyzją biznesową jest duża ilość danych. Duża ilość konkretnych danych może i tak, ale wielkość sama w sobie już nie.

komentarz 1 marca przez migatotech Początkujący (390 p.)

No więc w samej definicji czym są dane osobowe znajduje się odpowiedź na Twoje pytanie. Dane osobowe to są dane na podstawie których jesteś w stanie jednoznacznie rozpoznać osobę.

Jeśli dane są w formie zaszyfrowanej to już nie są to dane osobowe póki nie zostaną odszyfrowane.

Jak najbardziej wolumen danych jest decyzją biznesową. Facebook, Google itp. czy w założeniu modelu biznesowego tych firm nie jest trzymać jak najwięcej danych? Jest to decyzja biznesowa.

Natomiast co do samego Event Sourcingu to nie wprowadzasz tego wzorca jeśli nie chcesz mieć dodatkowej audytowalności systemu - np. ze względów legislacyjnych lub analitycznych j.w.

komentarz 1 marca przez tkz Nałogowiec (42,000 p.)

No więc w samej definicji czym są dane osobowe znajduje się odpowiedź na Twoje pytanie. Dane osobowe to są dane na podstawie których jesteś w stanie jednoznacznie rozpoznać osobę.

Super, ale RODO mówi o chronieniu tych danych, nie czym są.

Jeśli dane są w formie zaszyfrowanej to już nie są to dane osobowe póki nie zostaną odszyfrowane.

Artykuł o możliwości usunięciu danych(podajże 17) uważa inaczej.

Natomiast co do samego Event Sourcingu to nie wprowadzasz tego wzorca jeśli nie chcesz mieć dodatkowej audytowalności systemu - np. ze względów legislacyjnych lub analitycznych j.w.

1 odpowiedź

odpowiedź 1 marca przez reaktywny Nałogowiec (40,990 p.)

Fajny film, wciągająca seria! .....ale polecam prawdziwego pieska, z żywym psem jest lepszy kontakt ;)

Jakie planujesz kolejne fiilmy?

Może coś związanego z podziałem monolitu na mikroserwisy? Jak to poprawnie wykonać, na co zwróicić uwagę przy podziale, czym się kierować....?

komentarz 1 marca przez migatotech Początkujący (390 p.)

Dzięki, cieszę się :)

Następny będzie CQRS, a potem zobaczymy. Podział monolitu na mikroserwisy mi przechodził przez myśl, ale nie wiem czy na chwilę nie zostawię "twardych" wzorców projektowych i nie omówię albo architektury popularnych serwisów, albo czegoś na zasadzie architektury funkcjonalnej tj. omówienie ciekawych baz danych czy kolejek.