Comments on: Event Sourcing http://simon-says-architecture.com/2010/03/04/event-sourcing/ Szymon Pobiega about software engineering and architecture Fri, 03 Feb 2012 10:29:36 +0000 http://wordpress.org/?v=2.9.2 hourly 1 By: Szymon Pobiega http://simon-says-architecture.com/2010/03/04/event-sourcing/comment-page-1/#comment-669 Szymon Pobiega Mon, 08 Mar 2010 15:17:47 +0000 http://simon-says-architecture.com/?p=478#comment-669 @Procent Masz rację, modyfikację bazy produkcyjnej są w tym wypadku raczej trudne, jeśli nie niemożliwe. Jeśli błąd, który chcemy naprawić wynika z błędnego przetworzenia któregoś ze zdarzeń, możemy próbować naprawić je emitując sztuczne zdarzenie. Jeśli zaś jest on wynikiem błędnego wczytywania stanu ze zdarzenia (mało prawdopodobne) -- wystarczy poprawka kodu. Z drugiej strony możesz zawsze dowiedzieć się, co się dzieje w systemie, podpinając SSMS do relacyjnej bazy strony raportowo-zapytaniowej. Jęsli chodzi o brak wymagania posiadania bazy danych: Jonathan Olivier przytacza dobre argumenty za RDBMSem, jednak np. Greg Young opisuje swoje przygody z event sourcingiem na bazie własnej implementacji persystencji plikowej eventów. @Procent

Masz rację, modyfikację bazy produkcyjnej są w tym wypadku raczej trudne, jeśli nie niemożliwe. Jeśli błąd, który chcemy naprawić wynika z błędnego przetworzenia któregoś ze zdarzeń, możemy próbować naprawić je emitując sztuczne zdarzenie. Jeśli zaś jest on wynikiem błędnego wczytywania stanu ze zdarzenia (mało prawdopodobne) — wystarczy poprawka kodu.

Z drugiej strony możesz zawsze dowiedzieć się, co się dzieje w systemie, podpinając SSMS do relacyjnej bazy strony raportowo-zapytaniowej.

Jęsli chodzi o brak wymagania posiadania bazy danych: Jonathan Olivier przytacza dobre argumenty za RDBMSem, jednak np. Greg Young opisuje swoje przygody z event sourcingiem na bazie własnej implementacji persystencji plikowej eventów.

]]> By: Procent http://simon-says-architecture.com/2010/03/04/event-sourcing/comment-page-1/#comment-667 Procent Sun, 07 Mar 2010 00:45:26 +0000 http://simon-says-architecture.com/?p=478#comment-667 W sobotni wieczór po kilku brandy i browarku naszlo mnie na chwile refleksji o Event Sourcing:). Co do zalet - spierac sie nie mozna, są oczywiste. Mozliwosc odtworzenia stanu obiektu z dowolnego punktu w czasie faktycznie w niektorych systemach moze miec kluczowe znaczenie. W... niektorych. Zdawac sobie jednak nalezy sprawe z tego, ze nasza baza danych staje sie tak naprawde zbiorem nieczytelnych zer i jedynek. Jedna z korzysci tradycyjnego "relacyjnego" zapisu danych jest chociazby fakt, ze do kazdego projektu mozemy podpiac SQL Management Studio i wyciagnac z niego mase informacji o systemie. Dodatkowo, pomimo ze zasada "nigdy nie dotykaj produkcyjnej bazy" jest jak najbardziej sluszna, czasami nadchodzi sytuacja gdy MUSIMY zmienic jakąś wartosc w najmniej inwazyjny sposob z mozliwych. Normalnie - podpinamy sie SSMS do bazy i modyfikujemy co trzeba. Z event sourcing - takiej moliwosci nie ma, poniewaz wszystko jest zserializowane. Powiem wiecej - do tego nie potrzebujemy nawet bazy danych. Czy nie wystarczyloby wykorzystanie systemu kontroli wersji? Plik o nazwie "Guid EntityId" ze zmieniajacymi sie wartosciami, po kazdej modyfikacji autocomit... i mamy pelna historie i pelen backup za darmo. Ale zapedzilem sie za daleko:) W kazdym razie moim zdaniem niemoznosc "recznej" obrobki danych w "runtime" dyskwalifikuje Event Sourcing w wiekszosci systemow. Ale post - jak i cala seria - bardzo ciekawe. Czekam na obiecany odcinek o transakcjach:) W sobotni wieczór po kilku brandy i browarku naszlo mnie na chwile refleksji o Event Sourcing:). Co do zalet – spierac sie nie mozna, są oczywiste. Mozliwosc odtworzenia stanu obiektu z dowolnego punktu w czasie faktycznie w niektorych systemach moze miec kluczowe znaczenie. W… niektorych.
Zdawac sobie jednak nalezy sprawe z tego, ze nasza baza danych staje sie tak naprawde zbiorem nieczytelnych zer i jedynek. Jedna z korzysci tradycyjnego “relacyjnego” zapisu danych jest chociazby fakt, ze do kazdego projektu mozemy podpiac SQL Management Studio i wyciagnac z niego mase informacji o systemie. Dodatkowo, pomimo ze zasada “nigdy nie dotykaj produkcyjnej bazy” jest jak najbardziej sluszna, czasami nadchodzi sytuacja gdy MUSIMY zmienic jakąś wartosc w najmniej inwazyjny sposob z mozliwych. Normalnie – podpinamy sie SSMS do bazy i modyfikujemy co trzeba. Z event sourcing – takiej moliwosci nie ma, poniewaz wszystko jest zserializowane.
Powiem wiecej – do tego nie potrzebujemy nawet bazy danych. Czy nie wystarczyloby wykorzystanie systemu kontroli wersji? Plik o nazwie “Guid EntityId” ze zmieniajacymi sie wartosciami, po kazdej modyfikacji autocomit… i mamy pelna historie i pelen backup za darmo. Ale zapedzilem sie za daleko:)
W kazdym razie moim zdaniem niemoznosc “recznej” obrobki danych w “runtime” dyskwalifikuje Event Sourcing w wiekszosci systemow.
Ale post – jak i cala seria – bardzo ciekawe. Czekam na obiecany odcinek o transakcjach:)

]]> By: Thomas http://simon-says-architecture.com/2010/03/04/event-sourcing/comment-page-1/#comment-665 Thomas Thu, 04 Mar 2010 22:59:30 +0000 http://simon-says-architecture.com/?p=478#comment-665 Tak wlasnie sobie pomyslalem, ze w przypadku kiedy trzeba bedzie dostarczyc klientowi raporty/statystyki, trzeba bedzie sie gimnastykowac aby cos takiego zrobic. Z bazy relacyjnej jest to relatywnie proste. Masz moze jakies wskazowki jak to zrobic ? Przyklad DDD jest dosc skomplikowany jesli chodzi o rozpoczecie poznawania CQRS i jego aplikacji. Chetnie bym zaczal od prostego modelu domeny powiedzmy z 3 Entities (moze nie ma sensu w przyparku CQRS). Moglbys powiedziec co minimalnie jest potrzebne aby moc to zrobic (event sourcing lub nie, itp) ? Tak wlasnie sobie pomyslalem, ze w przypadku kiedy trzeba bedzie dostarczyc klientowi raporty/statystyki, trzeba bedzie sie gimnastykowac aby cos takiego zrobic. Z bazy relacyjnej jest to relatywnie proste. Masz moze jakies wskazowki jak to zrobic ?

Przyklad DDD jest dosc skomplikowany jesli chodzi o rozpoczecie poznawania CQRS i jego aplikacji. Chetnie bym zaczal od prostego modelu domeny powiedzmy z 3 Entities (moze nie ma sensu w przyparku CQRS). Moglbys powiedziec co minimalnie jest potrzebne aby moc to zrobic (event sourcing lub nie, itp) ?

]]> By: Szymon Pobiega http://simon-says-architecture.com/2010/03/04/event-sourcing/comment-page-1/#comment-664 Szymon Pobiega Thu, 04 Mar 2010 17:14:28 +0000 http://simon-says-architecture.com/?p=478#comment-664 Dzięki:) Z tą bazą raportową może być ciężko, bo w rozwiązaniach, które do tej pory robiłem była ona raportowa tylko z nazwy -- służyła praktycznie wyłącznie do realizacji zapytań. Dzięki:) Z tą bazą raportową może być ciężko, bo w rozwiązaniach, które do tej pory robiłem była ona raportowa tylko z nazwy — służyła praktycznie wyłącznie do realizacji zapytań.

]]> By: Thomas http://simon-says-architecture.com/2010/03/04/event-sourcing/comment-page-1/#comment-663 Thomas Thu, 04 Mar 2010 11:33:59 +0000 http://simon-says-architecture.com/?p=478#comment-663 Super post. Sledze twoje poczynania w sprawie CQRS od pewnego juz czasu i naprawde zaczyna mi sie to podobac. Jesli mozna by bylo zamowic jakis post to chetnie bym poczytal o bazie raportowej. Jak stworzyc prawdziwa baze raportowa itd. Super post. Sledze twoje poczynania w sprawie CQRS od pewnego juz czasu i naprawde zaczyna mi sie to podobac.
Jesli mozna by bylo zamowic jakis post to chetnie bym poczytal o bazie raportowej. Jak stworzyc prawdziwa baze raportowa itd.

]]>