Temat: Event sourcing

Jakub W.:
Dobry pattern to taki który ostatecznie przyspiesza / ułatwia realizację projektu.

to zależy co nazywasz projektem, bo jeżeli projektem nazwiesz "wytworzenie" a nie włączysz do niego "utrzymanie", to wszystkie wzorce są bez sensu gdyż większość z nich jest nastawiona na "przyszłe zmiany i zarządzanie", one komplikują "prostą" strukturę...

najprostszym wzorcem dający niemalże natychmiastowe wyniki jest "Boski Obiekt".

Oczywiście trzeba wiedzieć jak danego patternu uzyc.

:) ano...

Temat: Event sourcing

Jakub W.:
Absurdem można nazwać wprowadzenie dużej, niewymaganej ani przez biznes ani przez technologię, zmiany do aplikacji tylko po to, żeby sprawdzić czy przypadkiem czegoś ta zmiana nie usprawnia.

Ciężko się z tym nie zgodzić, nigdy w życiu nie próbował bym przerabiać istniejącego systemu na ES. Tak głęboki refactor to rzecz, której się po prostu nie robi, nie ważne czy na ES, czy na cokolwiek innego... Rozważam ES jako potencjalny pattern do nowych systemów.

ES potencjalnie rozwiązuje tylko te problemy, które już zostały rozwiązane. Co gorsza - robi to gorzej od istniejących narzędzi. Analogicznie jak z logiem.

Problem w tym, że w tym momencie to jedna wielka niewiadoma. Takie stanowcze stwierdzenia nie mogą być formułowane na podstawie przypuszczeń. Co gorsza moim zdaniem nikt z nas nawet do końca nie wie co to jest ES... dlatego ja jestem daleki od oceniania co jest lepsze/gorsze na takim etapie.

ES nie powstał w celu usprawnienia debugowania "trudnych błedów" więc nie należy go do tego stosować.

Pełna racja, nie powstał specjalnie do tego. Nie wiem dlaczego tak mocno zaczepiłeś się na tym debugowaniu... debugowanie to tylko jedna pozycja z listy.

.......
W przypadku ES sprawa wygląda inaczej - najpierw zdefiniowano wzorzec a następnie szuka się dla niego zastosowania "bo na pewno w czymś jest najlepsze"
Z punktu widzenia inżynierii to jest absurd.

No i tutaj się z tobą nie zgadzam. Moim zdaniem są poważne argumenty świadczące na plus ES i istnieją problemy, które mogą być dzięki temu łatwiej rozwiązane. Zresztą wrodzona ciekawość każde rozgrzebać temat, bo jest po prostu interesujący.

Szanuje naszą różnicę zdań i w gruncie rzeczy jest to bardzo dobre zjawisko. Prosił bym tylko o więcej argumentów, analiz, czy przykładów, mniej stwierdzeń... Zaraz ta rozmowa zamieni się w typową rozmowę z "Dnia Świra", czyli argumentacja w stylu "moja prawda jest prawdziwsza".

Temat: Event sourcing

Jarosław Ż.:

Jakub W.:
Dobry pattern to taki który ostatecznie przyspiesza / ułatwia realizację projektu.

to zależy co nazywasz projektem, bo jeżeli projektem nazwiesz "wytworzenie" a nie włączysz do niego "utrzymanie", to wszystkie wzorce są bez sensu gdyż większość z nich jest nastawiona na "przyszłe zmiany i zarządzanie", one komplikują "prostą" strukturę...

Project jako całość.

najprostszym wzorcem dający niemalże natychmiastowe wyniki jest "Boski Obiekt".

... Boski Obiekt też ma pewne zalety ;)

Temat: Event sourcing

Jakub W.:

Jarosław Ż.:

Jakub W.:
Dobry pattern to taki który ostatecznie przyspiesza / ułatwia realizację projektu.

to zależy co nazywasz projektem, bo jeżeli projektem nazwiesz "wytworzenie" a nie włączysz do niego "utrzymanie", to wszystkie wzorce są bez sensu gdyż większość z nich jest nastawiona na "przyszłe zmiany i zarządzanie", one komplikują "prostą" strukturę...

Project jako całość.

najprostszym wzorcem dający niemalże natychmiastowe wyniki jest "Boski Obiekt".

... Boski Obiekt też ma pewne zalety ;)

jakie (poza szybkim powstaniem)? :)

Temat: Event sourcing

ES potencjalnie rozwiązuje tylko te problemy, które już zostały rozwiązane. Co gorsza - robi to gorzej od istniejących narzędzi. Analogicznie jak z logiem.

Problem w tym, że w tym momencie to jedna wielka niewiadoma.

Yhm .. niewiadoma stworzona przez człowieka.

Takie stanowcze stwierdzenia nie mogą być formułowane na podstawie przypuszczeń.

To proszę, podaj chociaż jeden problem związany z tworzeniem / rozwojem systemów IT, który ES rozwiązuje "lepiej" niż istniejące narzędzia / rozwiązania. Niech ten problem dotyczy bezpośrednio domeny, albo warstwy technicznej.

Jeśli nie uda ci się takiego znaleźć (stawiam 100zł że takiego nie znajdziesz) nie będzie to oznaczać, że takich nie ma. Po prostu cała dyskusja zostanie sprowadzona do poziomu _wiary_.

Co gorsza moim zdaniem nikt z nas nawet do końca nie wie co to jest ES... dlatego ja jestem daleki od oceniania co jest lepsze/gorsze na takim etapie.

A wierzysz w duchy ? :)
W sieci jest masa materiałów o "prawdziwych duchach" z drugiej strony, nie mogłem znaleźć niczego w rodzaju "Event sourcing działa".

ES nie powstał w celu usprawnienia debugowania "trudnych błedów" więc nie należy go do tego stosować.

Pełna racja, nie powstał specjalnie do tego.
Nie wiem dlaczego tak mocno zaczepiłeś się na tym debugowaniu... debugowanie to tylko jedna pozycja z listy.

hm ... wspomnij o kolejnej :)

.......
W przypadku ES sprawa wygląda inaczej - najpierw zdefiniowano wzorzec a następnie szuka się dla niego zastosowania "bo na pewno w czymś jest najlepsze"
Z punktu widzenia inżynierii to jest absurd.

No i tutaj się z tobą nie zgadzam. Moim zdaniem są poważne argumenty świadczące na plus ES i istnieją problemy, które mogą być dzięki temu łatwiej rozwiązane.

Czy te argumenty to Martin Fowler i Greg Young ? :)

Zresztą wrodzona ciekawość każde rozgrzebać temat, bo jest po prostu interesujący.
Szanuje naszą różnicę zdań i w gruncie rzeczy jest to bardzo dobre zjawisko. Prosił bym tylko o więcej argumentów, analiz, czy przykładów, mniej stwierdzeń...

Analiza / argument - autor wzorca nie określił celu stosowania;
Przykład - ES nie jest najlepszą metodą usuwania "problematycznych" błędów.

Zaraz ta rozmowa zamieni się w typową rozmowę z "Dnia Świra", czyli argumentacja w stylu "moja prawda jest prawdziwsza".

...

Temat: Event sourcing

Jarosław Ż.:

Jakub W.:

Jarosław Ż.:

Jakub W.:
Dobry pattern to taki który ostatecznie przyspiesza / ułatwia realizację projektu.

to zależy co nazywasz projektem, bo jeżeli projektem nazwiesz "wytworzenie" a nie włączysz do niego "utrzymanie", to wszystkie wzorce są bez sensu gdyż większość z nich jest nastawiona na "przyszłe zmiany i zarządzanie", one komplikują "prostą" strukturę...

Project jako całość.

najprostszym wzorcem dający niemalże natychmiastowe wyniki jest "Boski Obiekt".

... Boski Obiekt też ma pewne zalety ;)

jakie (poza szybkim powstaniem)? :)

Wymusza organizację / synergię pracy (w jednej klasie funkcjonalności nie mogą się powielać), wymusza sprawną komunikację w obrębie zespołu, zdecydowanie upraszcza proces analizy i implementacji "bo to tylko jedna klasa" eh... chroni środowisko... :)

Proszę wybaczyć; to robota dla np. Martina Fowlera :)Ten post został edytowany przez Autora dnia 04.10.13 o godzinie 20:08

Temat: Event sourcing

Jakub W.:

... Boski Obiekt też ma pewne zalety ;)

jakie (poza szybkim powstaniem)? :)

Wymusza organizację / synergię pracy (w jednej klasie funkcjonalności nie mogą się powielać), wymusza sprawną komunikację w obrębie zespołu, zdecydowanie upraszcza proces analizy i implementacji "bo to tylko jedna klasa" eh... chroni środowisko... :)

no dobra ale jak funkcji jest więcej...;)

Temat: Event sourcing

Jakub W.:
Przykład - ES nie jest najlepszą metodą usuwania "problematycznych" błędów.

To dalej tylko i wyłącznie stwierdzenie, bardzo ogólne i nieuzasadnione niczym.

To proszę, podaj chociaż jeden problem związany z tworzeniem / rozwojem systemów IT, który ES rozwiązuje "lepiej" niż istniejące narzędzia / rozwiązania.

No to jedziemy, pierwsza i najbardziej oczywista rzecz: audyt.

Masz sporządzić dane audytowe z systemu, np. ile razy dany użytkownik wykonał dają akcję, ile łącznie zamówień/faktur/złotych przerobił w danym miesiącu ?

Ze statycznym modelem danych musisz wiedzieć, że takie dane będą potrzebne, zaimplementować moduł, który będzie odpowiadał za kompletowanie danych audytowych. Jeśli klient będzie chciał danych, które nie są kompletowane, to jedyne co możesz odpowiedzieć: "nie da się, nie było tego w specyfikacji". W przypadku ES, nie ma z tym żadnych problemów.

Z drugiej strony jeśli zrobisz moduł audytowy/log zapisujący wszystko co się stało, no to gratulację, bo to pierwszy krok implementacji ES. ES pokazuje jak na tak szczegółowym "logu" zaimplementować domenę, dzięki temu nie ma potrzeby statycznego modelu, ani modułu audytowego.

Podsumowując, ES może być przydatny w aplikacjach, w których potrzebna jest szczegółowa historia. Pozwala zbudować domenę na zbiorze eventów, załatwiając zapis staniu, audyt i log za jednym razem.

Temat: Event sourcing

Marcin M.:
Masz sporządzić dane audytowe z systemu, np. ile razy dany użytkownik wykonał dają akcję, ile łącznie zamówień/faktur/złotych przerobił w danym miesiącu ?

to lista obiektów biznesowych wytworzonych przez określona osobę,

Ze statycznym modelem danych musisz wiedzieć, że takie dane będą potrzebne, zaimplementować moduł, który będzie odpowiadał za kompletowanie danych audytowych. Jeśli klient będzie chciał danych, które nie są kompletowane, to jedyne co możesz odpowiedzieć: "nie da się, nie było tego w specyfikacji". W przypadku ES, nie ma z tym żadnych problemów.

wybacz ale to chyba najgorszy sposób jaki znam, by uzyskać funkcjonalność "audyt" w powyższym rozumieniu

Z drugiej strony jeśli zrobisz moduł audytowy/log zapisujący wszystko co się stało, no to gratulację, bo to pierwszy krok implementacji ES. ES pokazuje jak na tak szczegółowym "logu" zaimplementować domenę, dzięki temu nie ma potrzeby statycznego modelu, ani modułu audytowego.

wystarczy, że każdy dokument będzie zawierał informacje o swoim twórcy, żaden problem. wszelkie raporty jak "nie pilne" to bezpośrednio z tych obiektów a jak częste i pilne to dodaję CQRS

Podsumowując, ES może być przydatny w aplikacjach, w których potrzebna jest szczegółowa historia. Pozwala zbudować domenę na zbiorze eventów, załatwiając zapis staniu, audyt i log za jednym razem.

nadal odnosze wrażenie, że pałujemy się z pełnym modelem relacyjnym danych w tle...

Temat: Event sourcing

Jarosław Ż.:
to lista obiektów biznesowych wytworzonych przez określona osobę,

wybacz ale to chyba najgorszy sposób jaki znam, by uzyskać funkcjonalność "audyt" w powyższym rozumieniu

wystarczy, że każdy dokument będzie zawierał informacje o swoim twórcy, żaden problem. wszelkie raporty jak "nie pilne" to bezpośrednio z tych obiektów a jak częste i pilne to dodaję CQRS

Rzeczywiście przykład faktur/dokumentów nie jest dobry, bo wszystkie potrzebne dane są zachowywane w modelu domeny. Jednak nie zawsze tak jest.
Czasem operację polegają na modyfikacji obiektu, nie na stworzeniu nowego. W takim wypadku dane są nadpisywane i bez mechanizmów śledzących zmiany, są one tracone. ES śledzi wszystkie wejściowe dane, więc można z nich zawsze wyprowadzić wszystko co kiedykolwiek było zrobione w systemie.

nadal odnosze wrażenie, że pałujemy się z pełnym modelem relacyjnym danych w tle...

Niestety nie potrafię zrozumieć dlaczego...

Temat: Event sourcing

Marcin M.:
Rzeczywiście przykład faktur/dokumentów nie jest dobry, bo wszystkie potrzebne dane są zachowywane w modelu domeny. Jednak nie zawsze tak jest.
Czasem operację polegają na modyfikacji obiektu, nie na stworzeniu nowego. W takim wypadku dane są nadpisywane i bez mechanizmów śledzących zmiany, są one tracone. ES śledzi wszystkie wejściowe dane, więc można z nich zawsze wyprowadzić wszystko co kiedykolwiek było zrobione w systemie.

Podałeś przykład, który tępię :), np. wystawionej już faktury się nie modyfikuje :), uważam, że wiele problemów z oprogramowaniem jest generowanych w wyniku prób "łamania praw przyrody", użytkownik np. żąda w wymaganiach cofania się w czasie (albo moich ukochanych ujemnych stanów w magazynie :)) a "głupi" programista obiecuje, że to oprogramuje, zaczyna się lawina idiotycznych żądań i prób logicznej implementacji braku logiki ... to ślepa uliczka, nie jeden projekt został tak rozwalony.

nadal odnosze wrażenie, że pałujemy się z pełnym modelem relacyjnym danych w tle...

Niestety nie potrafię zrozumieć dlaczego...

ja też...

Temat: Event sourcing

Marcin M.:

Jakub W.:
Przykład - ES nie jest najlepszą metodą usuwania "problematycznych" błędów.

To dalej tylko i wyłącznie stwierdzenie, bardzo ogólne i nieuzasadnione niczym.

Jak rozumiem, nie jesteś w stanie podać (albo wymyślić) przewag logowania nad radykalną zmianą w mechanizmach persystencji danych...

To proszę, podaj chociaż jeden problem związany z tworzeniem / rozwojem systemów IT, który ES rozwiązuje "lepiej" niż istniejące narzędzia / rozwiązania.

No to jedziemy, pierwsza i najbardziej oczywista rzecz: audyt.
Masz sporządzić dane audytowe z systemu, np. ile razy dany użytkownik wykonał dają akcję, ile łącznie zamówień/faktur/złotych przerobił w danym miesiącu ?

Jak forma zapisu / odtwarzania stanu obiektu automatycznie zagwarantować pewne funkcjonalności biznesowe ?

Kim jest ten "użytkownik" i co to znaczy "przerobił" ?

Jeśli wystawił - w sytuacji gdy aplikacja nie została zaprojektowana tak, żeby "zapamiętywać" kto (pracownik) daną fakturę wystawił (a nie musi), to żadne ES (ani nic innego) takich danych nie udostępni.

Potrzeba (np. w celu umożliwienia audytu) zapisywania "użytkownika przerabiającego faktury" jest częścią funkcjonalności biznesowych i to właśnie w tej warstwie (biznesowej) powinna być realizowana.

Ze statycznym modelem danych musisz wiedzieć, że takie dane będą potrzebne,

przy ES nie trzeba wiedzieć ?

zaimplementować moduł, który będzie odpowiadał za kompletowanie danych audytowych.

no niestety...

Jeśli klient będzie chciał danych, które nie są kompletowane, to jedyne co możesz odpowiedzieć: "nie da się, nie było tego w specyfikacji".

Jeśli klient będzie mnie prosić o dane których wcześniej nie chciał, to uznam, że mu odbiło.
W sumie ... to jest materiał na dobry skecz ;)

Klient: Potrzebuję danych (i funkcjonalności) o których nie był słowa w dokumentacji
Wykonawca: Mamy je
Klient (zakończenie 1): Super. Jesteście super wykonawcami (absurdalna potrzeba, absurdalna realizacja)
Klient (zakończenie 2): Jakie to są dane ? Nie jestem pewien czego potrzebuję.
Klient (zakończenie 3): Tylko sprawdzałem - kończę z wami współpracę ponieważ marnujecie mój czas i pieniądze - jeśli nie ma czegoś w specyfikacji to nie ma być tego w systemie.

W przypadku ES, nie ma z tym żadnych problemów.

ES rozwiązuje problem źle zaprojektowanej domeny aplikacji ...
a co z problemem głodu ? ;)

Z drugiej strony jeśli zrobisz moduł audytowy/log zapisujący wszystko co się stało,

"Zapisuje wszystko" to ES.
Funkcjonalności audytowe to cześć funkcjonalności biznesowej, a więc robota dla analityka.

no to gratulację, bo to pierwszy krok implementacji ES.

To nie ma nic wspólnego z ES.
Logowanie to logowanie. ES przechowywanie stanu systemu w formie listy / historii zmian obiektów biznesowych.

ES pokazuje jak na tak szczegółowym "logu" zaimplementować domenę, dzięki temu nie ma potrzeby statycznego modelu, ani modułu audytowego.

To skąd te wątpliwości ? Jak chcesz, to mogę napisać jak doskonale ES sprawdziło się w projekcie w którym brałem udział :) Może chodzić o wszystko o debugowanie, audyt ... logikę temporalną.. co tam chcesz.

A na serio: ES to taka "błyszcząca rzecz" którą można sprzedać (a właściwie z niej szkolić) Indianom (czyli osobom które jeszcze się nie nauczyły, że IT to dziedzina inżynierii).

Temat: Event sourcing

Jarosław Ż.:
Podałeś przykład, który tępię :), np. wystawionej już faktury się nie modyfikuje :), uważam, że wiele problemów z oprogramowaniem jest generowanych w wyniku prób "łamania praw przyrody", użytkownik np. żąda w wymaganiach cofania się w czasie (albo moich ukochanych ujemnych stanów w magazynie :)) a "głupi" programista obiecuje, że to oprogramuje, zaczyna się lawina idiotycznych żądań i prób logicznej implementacji braku logiki ... to ślepa uliczka, nie jeden projekt został tak rozwalony.

Dlatego też przykład faktur i ogólnie niemodyfikowalnych dokumentów jest zły do pokazania zjawiska, o którym mówię.
Znacznie lepszym przykładem było by np. śledzenie paczek. Paczka ma różne statusy i jest w rękach wielu ludzi podczas cyklu życia. W takim wypadku wielokrotnie modyfikujesz obiekt biznesowy i moim zdaniem zapis "zdarzeniowy" miał by rację bytu.

Temat: Event sourcing

Marcin M.:
Dlatego też przykład faktur i ogólnie niemodyfikowalnych dokumentów jest zły do pokazania zjawiska, o którym mówię.
Znacznie lepszym przykładem było by np. śledzenie paczek. Paczka ma różne statusy i jest w rękach wielu ludzi podczas cyklu życia. W takim wypadku wielokrotnie modyfikujesz obiekt biznesowy i moim zdaniem zapis "zdarzeniowy" miał by rację bytu.

taki obiekt to agregat zawierający między innymi obiekty reprezentujące kolejne zdarzenia, jaką wartość tu wnosi (i czym jest) ES? Zakładam, że - powtarzając za Jakubem - padło takie oczekiwanie na etapie analizy wymagań.Ten post został edytowany przez Autora dnia 06.10.13 o godzinie 21:29

Temat: Event sourcing

Jakub W.:
Jeśli klient będzie mnie prosić o dane których wcześniej nie chciał, to uznam, że mu odbiło.
W sumie ... to jest materiał na dobry skecz ;)

Wiesz jak jest z klientami i ze zmianami wymagań : ] W idealnym świecie z pewnością klient przekazał by Ci w pierwszej wersji wszystkie wymagania. Zresztą są jeszcze sytuację życiowe, w której projektujesz aplikacje dla własnej firmy i szczerze mówiąc w takim wypadku ja wolę mieć na dysku wszystko, co tylko jest możliwe.

Jeśli wystawił - w sytuacji gdy aplikacja nie została zaprojektowana tak, żeby "zapamiętywać" kto (pracownik) daną fakturę wystawił (a nie musi), to żadne ES (ani nic innego) takich danych nie udostępni.

Ze statycznym modelem danych musisz wiedzieć, że takie dane będą potrzebne,

przy ES nie trzeba wiedzieć ?

No właśnie nie trzeba, bo ES ma zapisane wszystkie dane wejściowe z datą i źródłem zmiany (zwykle chodzi o użytkownika). Statyczny model (bez dodatkowej implementacji audytu) nie przechowuje:
- chronologii i czasu zdarzeń
- zmian wielokrotnych tych samych danych
- danych o użytkowniku wykonującym (tutaj są wyjątki)

Wiadomo, że ES nie "zmaterializuje" nieznanych dla systemu danych, ale z pewnością może wyciągnąć więcej, niż model statyczny. No a model statyczny+masywny audyt to moim zdaniem więcej pracy niż sam ES.

Potrzeba (np. w celu umożliwienia audytu) zapisywania "użytkownika przerabiającego faktury" jest częścią funkcjonalności biznesowych i to właśnie w tej warstwie (biznesowej) powinna być realizowana.

No właśnie nie zawsze, tzn. nie koniecznie wymaganie klienta jest funkcjonalnością biznesową. Jeśli klient poprosi Cię o średni czas w ms procesowania jakiejś czynności biznesowej to wrzucisz te dane i logikę w obiekty biznesowe, no kidding...

To skąd te wątpliwości ? Jak chcesz, to mogę napisać jak doskonale ES sprawdziło się w projekcie w którym brałem udział :) Może chodzić o wszystko o debugowanie, audyt ... logikę temporalną.. co tam chcesz.

O super, serio robiłeś projekt z ES ? Jestem bardzo ciekawy co było głównymi problemami i jak to się zakończyło.

Temat: Event sourcing

Wiesz jak jest z klientami i ze zmianami wymagań : ] W idealnym świecie z pewnością klient przekazał by Ci w pierwszej wersji wszystkie wymagania. Zresztą są jeszcze sytuację życiowe, w której projektujesz aplikacje dla własnej firmy i szczerze mówiąc w takim wypadku ja wolę mieć na dysku wszystko, co tylko jest możliwe.

była nie tu o tym nie raz mowa: nie da się stworzyć "rozwijalnej" aplikacji jeżeli za podstawę zbudujemy dla niej relacyjny (niemodyfikowalny po normalizacji) model danych....

Temat: Event sourcing

Jarosław Ż.:
taki obiekt to agregat zawierający między innymi obiekty reprezentujące kolejne zdarzenia, jaką wartość tu wnosi (i czym jest) ES? Zakładam, że - powtarzając za Jakubem - padło takie oczekiwanie na etapie analizy wymagań.

Agregat nie zawiera w sobie eventów. W gruncie rzeczy agregaty są bardzo podobne to tych w "standardowym" DDD. Różnica jest taka, że to nie stan agregatów jest zapisywany, tylko dane zdarzeń, które zaaplikowane po kolei do agregatu, pozwolą mu przeliczyć stan końcowy.

Być może jest to tylko "mainstreamowa" implementacja ES i być może da się to zrobić umieszczając eventy w agregacie, ale jeszcze się z czymś takim nie spotkałem : ]

A jaką wartość wnosi ES ? Moim zdaniem wiele rzeczy jest tu możliwych (postaram się je przeanalizować) i z pewnością skuszę się na podsumowanie z mojej strony, po dostatecznym rozgryzieniu tematu. Ale jedno mogę powiedzieć na pewno, ES przechowuje więcej niż model statyczny:
(cytat z postu do Jakuba)

- chronologii i czasu zdarzeń
- zmian wielokrotnych tych samych danych
- danych o użytkowniku wykonującym (tutaj są wyjątki)

Jarosław Ż.:
była nie tu o tym nie raz mowa: nie da się stworzyć "rozwijalnej" aplikacji jeżeli za podstawę zbudujemy dla niej relacyjny (niemodyfikowalny po normalizacji) model danych....

No i tutaj powiedziałeś kolejną rzecz, która dała mi do myślenia : ] Rzeczywiście znormalizowany model statyczny agregatów jest ciężki w rozwoju. Należy sobie zadać pytanie, jak na tą rozwijalność wpłynie składowanie danych eventów zamiast modelu agregatów ? Jak trudne będą zmiany różnych aspektów aplikacji w takiej architekturze ? Szczerze mówiąc nie mam pojęcia, ale ten temat pobudził moją wyobraźnię : ]

Temat: Event sourcing

Marcin M.:
Agregat nie zawiera w sobie eventów. W gruncie rzeczy agregaty są bardzo podobne to tych w "standardowym" DDD. Różnica jest taka, że to nie stan agregatów jest zapisywany, tylko dane zdarzeń, które zaaplikowane po kolei do agregatu, pozwolą mu przeliczyć stan końcowy.

To projektant decyduje o tym co zawiera agregat, w DDD jest tylko mowa o agregacie i ani słowa o tym co ma zawierać (lub nie zawierać), jak zaprojektuję w agregacie składową entity, kórej zadaniem będzie reprezentowanie (jakichś) zdarzeń to będą,

myślisz cały czas bazodanowo ;).

Rzeczywiście znormalizowany model statyczny agregatów jest ciężki w rozwoju. Należy sobie zadać pytanie, jak na tą rozwijalność wpłynie składowanie danych eventów zamiast modelu agregatów ? Jak trudne będą zmiany różnych aspektów aplikacji w takiej architekturze ? Szczerze mówiąc nie mam pojęcia, ale ten temat pobudził moją wyobraźnię : ]

wystarczy zrezygnować z pełnego modelu relacyjnego ...;) w aplikacji i od razu będzie lżej :)

Temat: Event sourcing

Marcin M.:

Jakub W.:
Jeśli klient będzie mnie prosić o dane których wcześniej nie chciał, to uznam, że mu odbiło.
W sumie ... to jest materiał na dobry skecz ;)

Wiesz jak jest z klientami i ze zmianami wymagań :]
W idealnym świecie z pewnością klient przekazał by Ci w pierwszej wersji wszystkie wymagania.
Zresztą są jeszcze sytuację życiowe, w której projektujesz aplikacje dla własnej firmy i szczerze mówiąc w takim wypadku ja wolę mieć na dysku wszystko, co tylko jest możliwe.

Jeśli wystawił - w sytuacji gdy aplikacja nie została zaprojektowana tak, żeby "zapamiętywać" kto (pracownik) daną fakturę wystawił (a nie musi), to żadne ES (ani nic innego) takich danych nie udostępni.

Ze statycznym modelem danych musisz wiedzieć, że takie dane będą potrzebne,

przy ES nie trzeba wiedzieć ?

No właśnie nie trzeba,

:)

bo ES ma zapisane wszystkie dane wejściowe z datą i źródłem zmiany (zwykle chodzi o użytkownika).

Nie ma :)

ES przechowuję historię zmian ob. biz., więc albo "data i źródło" będą częścią obiektu biz. albo takie informacje nie zostaną zapisane.

Potrzeba (np. w celu umożliwienia audytu) zapisywania "użytkownika przerabiającego faktury" jest częścią funkcjonalności biznesowych i to właśnie w tej warstwie (biznesowej) powinna być realizowana.

No właśnie nie zawsze, tzn. nie koniecznie wymaganie klienta jest funkcjonalnością biznesową. Jeśli klient poprosi Cię o średni czas w ms procesowania jakiejś czynności biznesowej to wrzucisz te dane i logikę w obiekty biznesowe, no kidding...

srsly bro ... :-)

To skąd te wątpliwości ? Jak chcesz, to mogę napisać jak doskonale ES sprawdziło się w projekcie w którym brałem udział :) Może chodzić o wszystko o debugowanie, audyt ... logikę temporalną.. co tam chcesz.

O super, serio robiłeś projekt z ES ? Jestem bardzo ciekawy co było głównymi problemami i jak to się zakończyło.

A jak może skończyć się project w którym decyzje podejmują ludzie, którzy nie widzą niczego dziwnego w np: znacznym komplikowaniu persystencji "bo może kiedyś się przyda" ? :)

Temat: Event sourcing

Jakub W.:

bo ES ma zapisane wszystkie dane wejściowe z datą i źródłem zmiany (zwykle chodzi o użytkownika).

Nie ma :)
ES przechowuję historię zmian ob. biz., więc albo "data i źródło" będą częścią obiektu biz. albo takie informacje nie zostaną zapisane.

Nie nie jest dokładnie tak jak mówisz, eventy nie są historią zmian biznesowych, tylko zdarzeniami, które wpływają na stan agregatu. Od implementacji agregatu zależy jak zinterpretuje dane zawarte w evencie.
Tak czy inaczej agregat biznesowy nie zachowuje danych o chronologii i czasie zdarzeń, a pakowanie tych wszystkich informacji do agregatu to może być jakiś nowy, oryginalny antywzorzec. To, że klient chce takiego audytu, nie znaczy, że magicznie staje się to składnikiem biznesu.

A jak może skończyć się project w którym decyzje podejmują ludzie, którzy nie widzą niczego dziwnego w np: znacznym komplikowaniu persystencji "bo może kiedyś się przyda" ? :)

No właśnie tego chcę się dowiedzieć : ] Pytanie czy komplikacja będzie warta zachodu i czy sama w sobie będzie tak "skomplikowana" jak się zdaje.

Polecam bardzo ładnie napisany artykuł:
http://lostechies.com/jimmybogard/2011/10/11/event-sou...

"But if you’re trying to understand why the current state is what it is, the final state is not nearly as useful as the series of events that led to that endpoint."