Temat: Event sourcing

Event sourcing to kolejny pattern z kanonu DDD (często polecany w połączeniu z CQRS), który od dłuższego czasu budzi moje zainteresowanie. W internecie można spotkać dużo przykładów, jak może to wyglądać, jednak ja jestem dość sceptyczny nastawiony.

Istotą event sourcingu jest składowanie stanu aplikacji używając serii biznesowych zdarzeń, które uruchomione po kolei dają ostateczny stan aplikacji. Dzięki temu dostajemy bardzo dużo nowych możliwości i załatwiamy część funkcjonalności od razu m.in.:
- historię i logowanie zmian stanu(który od razu tworzy nam funkcję historii w aplikacji)
- pełny backtrace, bardzo pomocny w debugowaniu
- możliwość "przewijania" aplikacji w czasie, cofania specyficznych zdarzeń, bardzo pomocne w testowaniu, integracji i migracjach

Jeśli dobrze to rozumiem, to stan jest w zdarzeniach, więc żeby wyciągnąć agregat w celu wykonania operacji, należy przekalkulować wszystkie eventy od początku ? Takie rozwiązanie jest zupełnie nierealne... Z pewnością trzeba będzie zrobić i tak statyczny "snapshot" całego stanu, tak by dało się na nim w pracować z sensowną wydajnością. Czyli mamy tutaj już dwa modele danych, oznaczające to samo, tylko jeden statyczny, drugi w zdarzeniach.

Powiedzmy, że chcemy do tego zastosować CQRS, w celu zwiększenia wydajności odczytu. Tworzymy więc zdenormalizowany obraz danych i od tej pory interfejs do zapytań używa właśnie tego obrazu. Czy tu czai się trzeci model danych i w związku z tym potrojony czas wykonywania zapisów i nadmiarowośc w bazach ? Czas na dev i maintenance też zwielokrotniony. Do tego mamy problemy z synchronizacją trzech modeli.

Nie chcę, żeby zabrzmiało to jak krytyka tego patternu. Nie miałem do czynienia z żadną taka aplikacją, dlatego wszystko co zamieściłem to tylko i wyłącznie moje przypuszczenia. Czy ma ktoś może doświadczenia w tej materii, lub widział to cudo w praktyce ?

Temat: Event sourcing

.Ten post został edytowany przez Autora dnia 13.08.16 o godzinie 21:38

Temat: Event sourcing

Paweł W.:
A gdybyś trzymał w bazie (czy gdzieś tam) aktualna wersję stanu a Eventy wykorzystywał do "cofania się w czasie" aby w razie potrzeby sprawdzić jaki był stan przed 5 eventami?

Dokładnie o takim rozwiązaniu napisałem:

Marcin M.:Z pewnością trzeba będzie zrobić i tak statyczny "snapshot"
całego stanu, tak by dało się na nim w pracować
z sensowną wydajnością.

Takie rozwiązane z pewnością polepszy wydajność, ale ma za to wiele wad:
- redundancja danych
- podwojone zapisy
- kolejny model do utrzymywania w bazie

Moim zdaniem ten problem wynika z niezrozumienia event sourcingu, z pewnością jest na to jakiś lepszy sposób.

Temat: Event sourcing

Marcin M.:
Event sourcing to kolejny pattern z kanonu DDD (często polecany w połączeniu z CQRS), który od dłuższego czasu budzi moje zainteresowanie.
W internecie można spotkać dużo przykładów, jak może to wyglądać, jednak ja jestem dość sceptyczny nastawiony.

Całkiem słusznie. Tworzenie historii zmian danego obiektu biznesowego (jeśli istnieje taka potrzeba biznesowa) na prawdę nie jest skomplikowane od strony programistycznej... po co ktoś miałby na to tworzyć specjalny pattern ?

Istotą event sourcingu jest składowanie stanu aplikacji używając serii biznesowych zdarzeń, które uruchomione po kolei dają ostateczny stan aplikacji. Dzięki temu dostajemy bardzo dużo nowych możliwości i załatwiamy część funkcjonalności od razu m.in.:
- historię i logowanie zmian stanu(który od razu tworzy nam funkcję historii w aplikacji)

Nam czyli komu ? Po co takie coś tworzyć, jeśli nie ma takiej potrzeby biznesowej ?
Należałby zadać pytanie, czy taki obiekt przechowujący zmianę jest częścią domeny czy też warstwy implementacji / technologicznej.

Jeśli ma być częścią domeny - dlaczego pisze się o nim w kontekście stanów i obiektów (The fundamental idea of Event Sourcing is that of ensuring every change to the state of an application is captured in an event object) a nie historii zmian.

Jeśli jest częścią warstwy technologicznej - jaki problem rozwiązuje / w jakim celu powstał ?

- pełny backtrace, bardzo pomocny w debugowaniu

Chodzi o domenę czy o "pomoc w debugowaniu" ?
Pomoc w debugowaniu kodu trudniejszego w napisaniu ...

- możliwość "przewijania" aplikacji w czasie, cofania specyficznych zdarzeń, bardzo pomocne w testowaniu, integracji i migracjach

... reszty nie komentuję :)

Temat: Event sourcing

Jakub W.:
Jeśli ma być częścią domeny - dlaczego pisze się o nim w kontekście stanów i obiektów (The fundamental idea of Event Sourcing is that of ensuring every change to the state of an application is captured in an event object) a nie historii zmian.

Jeśli jest częścią warstwy technologicznej - jaki problem rozwiązuje / w jakim celu powstał ?

Wiesz nie ja to wymyśliłem i na razie nie mam opinii na ten temat (bo nie mam żadnym doświadczeń by tą opinię mieć). Z tego co wiem eventy należą do warstwy technologicznej, a to czy będą odpowiadały za historię w aplikacji to już raczej decyzja w zależności od potrzeb.

Chodzi o domenę czy o "pomoc w debugowaniu" ?
Pomoc w debugowaniu kodu trudniejszego w napisaniu ...

Nie ulega wątpliwości, że pełna historia zmiany stanu ułatwi debugowanie błędów polegających na złym stanie aplikacji, możesz od razu wytropić który event spowodował błąd.

- możliwość "przewijania" aplikacji w czasie, cofania specyficznych zdarzeń, bardzo pomocne w testowaniu, integracji i migracjach

... reszty nie komentuję :)

Po raz kolejny mówię, że nie ja to wymyśliłem. M. in. tutaj jest o zaletach ES:
http://msdn.microsoft.com/en-us/library/jj591559.aspx

Dlatego też proszę o opinię/doświadczenia odnośnie tego patternu, a nie o ocenę tego co napisałem.

Temat: Event sourcing

Nie ulega wątpliwości, że pełna historia zmiany stanu ułatwi debugowanie błędów polegających na złym stanie aplikacji, możesz od razu wytropić który event spowodował błąd.

ale to problem techniczny a nie biznesowy,

> > - możliwość "przewijania" aplikacji w czasie, cofania

specyficznych zdarzeń, bardzo pomocne w testowaniu, integracji i migracjach

z perspektywy biznesowej "czas się nie cofa", implementacja czegoś takiego to zmora wielu aplikacji: mój ulubiony temat żartów na temat tego typu pomysłów to "wycofanie wystawionej faktury" totalnie pozbawione podstaw prawnych i fizycznych (przypadkiem, który kocham to "wycofanie" w systemie faktury wysłanej już klientowi).

Po raz kolejny mówię, że nie ja to wymyśliłem. M. in. tutaj jest o zaletach ES:
http://msdn.microsoft.com/en-us/library/jj591559.aspx

cytat z powyższej strony: "Events are immutable" czyli w ModeluDziedziny nie ma sensu.

Moim zdaniem (przykład ze strony MSDN) jest to pewne rozwiązanie np. odwołania rezerwacji czyli powrotu do stanu z przed rezerwacji. Użycie "powrotu do stany z przed" postrzegam to jako poważny błąd biznesowy, gdyż taki fakt musi być w historii pracy ludzi i firmy zarejestrowany (nie można uznać odwołania rezerwacji za cofnięcie w czasie stanu systemu, należy "prze-procesować" takie odwołanie, po tym zostają "dokumenty". Przypomnę, że np. fakturę legalnie można skorygować a nie usunąć.

Dlatego też proszę o opinię/doświadczenia odnośnie tego patternu, a nie o ocenę tego co napisałem.

Jeżeli ktoś tego uzywa w Controller, nic mi do tego.

Temat: Event sourcing

Marcin M.:

Jakub W.:
Jeśli ma być częścią domeny - dlaczego pisze się o nim w kontekście stanów i obiektów (The fundamental idea of Event Sourcing is that of ensuring every change to the state of an application is captured in an event object) a nie historii zmian.

Jeśli jest częścią warstwy technologicznej - jaki problem rozwiązuje / w jakim celu powstał ?

Wiesz nie ja to wymyśliłem i na razie nie mam opinii na ten temat (bo nie mam żadnym doświadczeń by tą opinię mieć).

Ale ja nie chciałem żebyś mi odpowiadał :) To powinien wyjaśnić autor koncepcji w momencie publikacji swojego pomysłu. Nie zrobił tego (z resztą nawet nie wiadomo kto to jest). ES to takie narzędzie o którym nie wiadomo w jakim dokładnie celu powstało.

Chodzi o domenę czy o "pomoc w debugowaniu" ?
Pomoc w debugowaniu kodu trudniejszego w napisaniu ...

Nie ulega wątpliwości, że pełna historia zmiany stanu ułatwi debugowanie błędów polegających na złym stanie aplikacji, możesz od razu wytropić który event spowodował błąd.

Błędy biorą się z wadliwego działania kodu. Jak lista eventów może wskazać, gdzie w kodzie jest bug ?

- możliwość "przewijania" aplikacji w czasie, cofania specyficznych zdarzeń, bardzo pomocne w testowaniu, integracji i migracjach

... reszty nie komentuję :)

Po raz kolejny mówię, że nie ja to wymyśliłem.

Niczego takiego nie twierdzę. Powiedzmy, że jednoczesne czytanie o ES i CQRS przepala mi bezpieczniki absurdu :)

M. in. tutaj jest o zaletach ES:
http://msdn.microsoft.com/en-us/library/jj591559.aspx

:]

Dlatego też proszę o opinię/doświadczenia odnośnie tego patternu, a nie o ocenę tego co napisałem.

Moja opinia (mam nadzieję, że nigdy nie zdobędę doświadczena w ES):
ES jest bezużyteczny - nie wiadomo w jakim celu powstał i nie wiadomo jaki konkretnie problem rozwiązuje.

Temat: Event sourcing

Jakub W.:
ES jest bezużyteczny - nie wiadomo w jakim celu powstał i nie wiadomo jaki konkretnie problem rozwiązuje.

Dzięki za opinię : ] Szczerze mówiąc też jestem pesymistycznie nastawiony to tego pomysłu, ale też jestem daleki od odrzucania patternu bez wiedzy czym dokładnie jest i jak działa w praktyce. Z pewnością coś Pan Fowler miał na myśli mówiąc o nim i mam zamiar dowidzieć się o co chodziło.

EDIT:

Jakub W.:
Błędy biorą się z wadliwego działania kodu. Jak lista eventów może wskazać, gdzie w kodzie jest bug ?

Porównajmy dwie sytuację: 1.masz standardowy "ostateczny" model danych, 2.masz eventy informujące o zmianach. Teraz mamy sytuację, że aplikacja działa x dni i w pewnym momencie użytkownik zauważa błędne dane:
1. jedyne co masz to błąd w danych, możesz polować na niego przeglądając/testując wszystkie funkcję, które mają wpływ na błędne dane, zauważ że poprawne dane mogą być nadpisane przez złe i stracone
2. masz błędny stan, który jest złożeniem x eventów, aplikujesz eventy po kolei i monitorujesz dane, jak bug się pojawi to wiesz dokładnie, który event powoduje błąd, nie ma szans na stratę danych, po poprawieniu kodu, puszczasz wszystkie eventy jeszcze raz i po problemieTen post został edytowany przez Autora dnia 02.10.13 o godzinie 12:53

Temat: Event sourcing

Jarosław Ż.:
...

Mam wrażenie, że odnosisz się do ES, tak jakby miał być to pattern do obsługi logiki domeny. ES to pattern architekturalny, który zakłada wyrażanie całego stanu aplikacji w ciągu eventów, zamiast jednego ostatecznego stanu.
Kombinacje w stylu "przewijania w czasie" to tylko i wyłącznie techniczne możliwości, które nigdy nie są używane w realizacji logiki domenowej.

Temat: Event sourcing

Jarosław Ż.:
...

Mam wrażenie, że odnosisz się do ES, tak jakby miał być to pattern do obsługi logiki domeny. ES to pattern architekturalny, który zakłada wyrażanie całego stanu aplikacji w ciągu eventów, zamiast jednego ostatecznego stanu.

chyba nie sugerujesz, ze komponent Dziedzinowy nie jest elementem tej "całej aplikacji"?

Kombinacje w stylu "przewijania w czasie" to tylko i wyłącznie techniczne możliwości, które nigdy nie są używane w realizacji logiki domenowej.

Chcesz się założyć? Prawie każda znana mi aplikacja pozwala na anulowanie faktury, zwrot do magazynu to nie raz "anulowanie" wydania, to plaga (podobna jak przeczące fizyce ujemne stany magazynowe).

W zasadzie pozostaje mi się tu zgodzić z Jakubem: jaki problem, poza złym projektowaniem, rozwiązuje ten "wzorzec"? Bo mi to jednak przypomina przykrywanie g...na gazetą. Ten post został edytowany przez Autora dnia 02.10.13 o godzinie 12:43

Temat: Event sourcing

Jarosław Ż.:
chyba nie sugerujesz, ze komponent Dziedzinowy nie jest elementem tej "całej aplikacji"?

Jest, ale wcale nie musi korzystać z historii ES do biznesowego "anulowania" operacji.

Kombinacje w stylu "przewijania w czasie" to tylko i wyłącznie techniczne możliwości, które nigdy nie są używane w realizacji logiki domenowej.

Chcesz się założyć? Prawie każda znana mi aplikacja pozwala na anulowanie faktury, zwrot do magazynu to nie raz "anulowanie" wydania, to plaga (podobna jak przeczące fizyce ujemne stany magazynowe).

Jeśli dobrze rozumiem ES, to w wypadku o którym mówisz nie było by czegoś takiego jak cofnięcie eventów w celu anulowania faktury, tylko zostanie dodany kolejny, który jest anulowaniem.

W zasadzie pozostaje mi się tu zgodzić z Jakubem: jaki problem, poza złym projektowaniem, rozwiązuje ten "wzorzec"? Bo mi to jednak przypomina przykrywanie g...na gazetą.

Bardzo możliwe, że macie rację. To, że moja wrodzona ciekawość każde mi rozgrzebać ten temat to inna sprawa : ]

Temat: Event sourcing

Marcin M.:

Kombinacje w stylu "przewijania w czasie" to tylko i wyłącznie techniczne możliwości, które nigdy nie są używane w realizacji logiki domenowej.

Chcesz się założyć? Prawie każda znana mi aplikacja pozwala na anulowanie faktury, zwrot do magazynu to nie raz "anulowanie" wydania, to plaga (podobna jak przeczące fizyce ujemne stany magazynowe).

Jeśli dobrze rozumiem ES, to w wypadku o którym mówisz nie było by czegoś takiego jak cofnięcie eventów w celu anulowania faktury, tylko zostanie dodany kolejny, który jest anulowaniem.

a powinna zostać dodana faktura korygująca

W zasadzie pozostaje mi się tu zgodzić z Jakubem: jaki problem, poza złym projektowaniem, rozwiązuje ten "wzorzec"? Bo mi to jednak przypomina przykrywanie g...na gazetą.

Bardzo możliwe, że macie rację. To, że moja wrodzona ciekawość każde mi rozgrzebać ten temat to inna sprawa : ]

tez tak (drążenie) mam :), staram się testować każdy pomysł zanim go użyję, odnoszę wrażenie, że poza podstawowym pakietem wzorców GoF, nowe to raczej lekarstwo na efekty projektów "agile"... bo kodowanie poprzedzane przemyśleniami, planowaniem, projektowaniem, nie maja takich problemów ;)

Temat: Event sourcing

Jarosław Ż.:
a powinna zostać dodana faktura korygująca

No to już jest kwestia czysto biznesowa, jak to nazwiemy i czym te zdarzenie w rzeczywistości będzie w domenie. Istotą jest to że dokładany jest kolejny event, który nie musi w żaden sposób odnosić się do poprzednich, czy wpływać na nie w jakikolwiek sposób.

tez tak (drążenie) mam :), staram się testować każdy pomysł zanim go użyję, odnoszę wrażenie, że poza podstawowym pakietem wzorców GoF, nowe to raczej lekarstwo na efekty projektów "agile"... bo kodowanie poprzedzane przemyśleniami, planowaniem, projektowaniem, nie maja takich problemów ;)

ES zaciekawił mnie bo odwraca podejście do persystencji danych aplikacji. W gruncie rzeczy stan aplikacji można rzeczywiście wyrazić jako stream eventów. Moim zdaniem daje to dodatkowe możliwości, teraz pytanie czy warte są zachodu i czy przypadkiem nie da się tego samego zrobić prościej niż przewracając persystencje do góry nogami.

Temat: Event sourcing

Marcin M.:

Jarosław Ż.:
a powinna zostać dodana faktura korygująca

No to już jest kwestia czysto biznesowa, jak to nazwiemy i czym te zdarzenie w rzeczywistości będzie w domenie.

to jest kluczowy problem wielu projektów: oprogramowanie nijak się ma do rzeczywistości dlatego uważam, że nie programista powinie je (część dziedzinową) projektować

tez tak (drążenie) mam :), staram się testować każdy pomysł zanim go użyję, odnoszę wrażenie, że poza podstawowym pakietem wzorców GoF, nowe to raczej lekarstwo na efekty projektów "agile"... bo kodowanie poprzedzane przemyśleniami, planowaniem, projektowaniem, nie maja takich problemów ;)

ES zaciekawił mnie bo odwraca podejście do persystencji danych aplikacji. W gruncie rzeczy stan aplikacji można rzeczywiście wyrazić jako stream eventów. Moim zdaniem daje to dodatkowe możliwości, teraz pytanie czy warte są zachodu i czy przypadkiem nie da się tego samego zrobić prościej niż przewracając persystencje do góry nogami.

hm... tu chyba mamy mieszanie paradygmatów: albo na poziomie logiki systemu operujemy pojęciem obiekt i zapominamy o "danych" albo cofamy się do systemów strukturalnych i mamy jakieś dane i jakieś funkcje.

Nie zapominajmy, że "persystencja" tu to utrwalanie obiektów a nie danych. Dane na dysku to jakaś implementacja "persystencji". te "eventy" to być może sensowne rozwiązanie dla motorów baz danych ale nie na poziomie logiki systemu.

Temat: Event sourcing

Marcin M.:

Jakub W.:
ES jest bezużyteczny - nie wiadomo w jakim celu powstał i nie wiadomo jaki konkretnie problem rozwiązuje.

Dzięki za opinię : ] Szczerze mówiąc też jestem pesymistycznie nastawiony to tego pomysłu, ale też jestem daleki od odrzucania patternu bez wiedzy czym dokładnie jest i jak działa w praktyce.

proponuję zainwestować czas w naukę rzeczy o których wiadomo czym są i jak działają w praktyce :)

Z pewnością coś Pan Fowler miał na myśli mówiąc o nim i mam zamiar dowidzieć się o co chodziło.

coś miał na myśli, ale nie wiadomo co ? ;)
to bardziej pasuje do "szamana" niż do "autorytetu" ...

EDIT:

Jakub W.:
Błędy biorą się z wadliwego działania kodu. Jak lista eventów może wskazać, gdzie w kodzie jest bug ?

Porównajmy dwie sytuację: 1.masz standardowy "ostateczny" model danych, 2.masz eventy informujące o zmianach.

1. W skrócie - mamy informację o tym jak zmieniał się stan "czegoś".

Teraz mamy sytuację, że aplikacja działa x dni i w pewnym momencie użytkownik zauważa błędne dane:
1. jedyne co masz to błąd w danych, możesz polować na niego przeglądając/testując wszystkie funkcję, które mają wpływ na błędne dane, zauważ że poprawne dane mogą być nadpisane przez złe i stracone

W jaki sposób określisz w którym dokładnie momencie pojawiły się "złe dane" (jak rozumiem, nie zostały one wygenerowane przez ostatnio wywołany use case) ?

... żeby znaleźć źródło błędu (i to przy założeniu, że nie ma walidacji danych) i tak musisz sprawdzić "wszystkie" (do momentu odnalezienia "z błędem") funkcje.

2. masz błędny stan, który jest złożeniem x eventów, aplikujesz eventy po kolei i monitorujesz dane, jak bug się pojawi to wiesz dokładnie,

To w zasadzie oznacza, że ludzie którzy pracują z danym systemem tak na prawdę nie wiedzą co robią. Skoro "ja" mogę znaleźć bug'a tam gdzie użytkownicy go nie widzą, to chyba jest coś nie tak, prawda ?

który event powoduje błąd, nie ma szans na stratę danych, po poprawieniu kodu, puszczasz wszystkie eventy jeszcze raz i po problemie

jak rozumiem - to jest żart.Ten post został edytowany przez Autora dnia 02.10.13 o godzinie 18:51

Temat: Event sourcing

Jakub W.:
proponuję zainwestować czas w naukę rzeczy o których wiadomo czym są i jak działają w praktyce :)

Gdyby każdy myślał w ten sposób, to do dzisiaj byśmy dalej kodowali w asemblerze.

coś miał na myśli, ale nie wiadomo co ? ;)
to bardziej pasuje do "szamana" niż do "autorytetu" ...

W nauce nie ma autorytetów, są tylko wybitni eksperci, których wieloletnie doświadczenie warto brać na poważnie. Nikt nie każe Ci się z nimi od razu zgadzać, ja tylko uważam, że ich idee są warte spróbowania.

Widzę, że porównanie debugowania spotkało się z zerowym zrozumieniem (być może też po części z mojej winy), więc spróbuje napisać to prościej, pokazując tylko i wyłącznie przewagę ES na tym polu:
ES ma przewagę w debugowaniu, bo zawiera zawsze kompletny zapis chronologiczny wszystkiego, co zdarzyło się w systemie. Stan systemu nie jest zapisywany statycznie, tylko jest wypadkową wszystkich eventów uruchomionych po kolei. Dzięki temu jesteśmy w stanie ze 100% dokładnością odtworzyć życie systemu event po evencie. Jeśli to twoim zdaniem nie daje przewagi w debugowaniu, to w takim razie to rozważanie nie ma dalszego sensu.

Temat: Event sourcing

Marcin M.:
W nauce nie ma autorytetów, są tylko wybitni eksperci, których wieloletnie doświadczenie warto brać na poważnie. Nikt nie każe Ci się z nimi od razu zgadzać, ja tylko uważam, że ich idee są warte spróbowania.

z tym warto sią zgodzić

ES ma przewagę w debugowaniu, bo zawiera zawsze kompletny zapis chronologiczny wszystkiego, co zdarzyło się w systemie. Stan systemu nie jest zapisywany statycznie, tylko jest wypadkową wszystkich eventów uruchomionych po kolei. Dzięki temu jesteśmy w stanie ze 100% dokładnością odtworzyć życie systemu event po evencie. Jeśli to twoim zdaniem nie daje przewagi w debugowaniu, to w takim razie to rozważanie nie ma dalszego sensu.

to "zwykły log" albo czegoś nie rozumiem...

Temat: Event sourcing

Tak sobie trochę myślałem i poczytałem na temate tego wzorca (nie używałem, więc wszystko opieram na przemyśleniach), ale wydaje mi się, że całkiem rozsądnym przykładem, gdzie można byłoby go zastosować to np. aplikacja do kodu review. I to zarówno pod względem logiki biznesowej, jak i technicznej implementacji.
Dodajemy plik (stan początkowy), a następnie nanosimy zmiany, które możemy podglądać. Chcemy mieć również możliwość oglądania tego, jak plik się zmieniał w ujęciu historycznym. Nie chodzi o debugowanie czy też wykonywanie nieuzasadnionych procesów.

Nie wydaje mi się, żeby Fowler'owi pojawiła się myśl, żeby każdym obiektem dziedziny zarządzać w ten sposób, bo to zwyczajnie byłoby nieopłacalne (implementacja) i niepotrzebne (logika).

Temat: Event sourcing

Jarosław Ż.:

ES ma przewagę w debugowaniu, bo zawiera zawsze kompletny zapis chronologiczny wszystkiego, co zdarzyło się w systemie. Stan systemu nie jest zapisywany statycznie, tylko jest wypadkową wszystkich eventów uruchomionych po kolei. Dzięki temu jesteśmy w stanie ze 100% dokładnością odtworzyć życie systemu event po evencie. Jeśli to twoim zdaniem nie daje przewagi w debugowaniu, to w takim razie to rozważanie nie ma dalszego sensu.

to "zwykły log" albo czegoś nie rozumiem...

Zgadzam się, że to "zykły log". Wydaje mi się, że istotne jest to do czego ten log ma być wykorzystywany :-)

Biznesowo nie widzę dobrego przykładu, ale technicznie ES daje ciekawe możliwości, np.:
- replikacja stanu aplikacji na zapasowy węzeł obliczeniowy (standby)
- możliwość przywrócenia stanu aplikacji do momentu sprzed testów (jednak aplikacja musiałby dla każdego typu zdarzenia posiadać _techniczną_ operację kompensującą, czyli np. usunięcie wystawionej faktury ; korektę traktuję jako operacj biznesową)
- aktualizacje rozproszonych cache
- replay zdarzeń na potrzeby zewnętrznego systemu ("nie przetworzylismy zdarzeń, bo system padł z braku miejsca na dysku i chcemy naprawić")

Oracle stosuje takiego loga jako mechanizm zapewnienia transakcyjności w swojej bazie danych (w szczególności spójności). Nie nazywa tego event sourcingiem, ale zasada jest ta sama. Zdarzenia z loga mogą być wykorzystane do "przewinięcia stanu wstecz/do przodu". Technicznie jest to "zwykły log", ale biznesowe konsekwencje są poważniejsze (możliwość odtworzenia danych z backapu, przywrócenia stanu bazy sprzed powstawnia błędu logicznego etc.).

Temat: Event sourcing

Paweł Grzegorz K.:
Oracle stosuje takiego loga jako mechanizm zapewnienia transakcyjności w swojej bazie danych (w szczególności spójności). Nie nazywa tego event sourcingiem, ale zasada jest ta sama.

i tak myślę, że ES to chyba nowy papierek na stare cukierki :)