Temat: Event sourcing

Jarosław Ż.:

Jakub W.:

Jarosław Ż.:

Jakub W.:

Jarosław Ż.:

Jakub W.:

2. Zapewni transparencje procesu pobierania danych / stanu. Programista / analityk nie musi korzystać z fabryk czy repozytoriów. Dane do agregatów są pobierane poprzez zwykłe wywołania funkcji / propertiesów z danego obiektu biznesowego

no fabryka to w 100% logika biznesowa a nie ORM... co ma więc fabryka do ORM?

Niekoniecznie. Fabryka jest odpowiedzialna jest za tworzenie obiektów biznesowych.
W przypadku "dobrego" ORM (np. Lightspeed formy Mindscape) obiekty biznesowe są tworzone przez ORM... Pewnie to będzie wymagać dodatkowego komentarza ;)

jeżeli zdefiniujemy wzorzec Fabryka jako "wiedza biznesowa o tworzeniu nowych agregatów biznesowych", to "odtworzenie" ich z "persystencji" nie jest ich wytwarzaniem, przywoływanie to niewidzialna (co sam zauwazyłeś) rola repozytorium

W celu uniknięcia nieporozumień proszę o przykład :)

3. Klasy / encje generowane przez ORM mogą być dowolnie rozszerzanie o metody biznesowe

w 1. napisałeś, że ORM to transparentna persystencja, od kiedy ORM generuje klasy/encje?

Narzędzia do zautomatyzowanego mapowania modelu relacyjnego na model encyjny (klas i relacji mędzy nimi) wchodzą w skład niektórych ORM.

ORM to dosłownie "object to relational mapping" a nie odwrotnie,

Nazwa generalnie jest głupia bo object może mieć dość dowolne (wzorzec dekoratora) relacje z reszta systemu podczas gdy.. a nieważne.

ORM to wyłącznie implementacja repozytorium a nie logika,

nom .. a fabryki ?

jeżeli jakiś ORM realizuje cokolwiek z logiki biznesowej to jest to "inna nieobiektowa" bajka

"inna nieobiektowa" bajka ?
Myślałem, że jeśli ORM dostarczający logikę biznesową jest senem wariata ... :)

Po wygenerowaniu modelu encyjnego można uzupełnić go o metody biznesowe tworząc tym samym model domeny który w żadnej swej częsci (brak fabryk, repozytoriów) nie będzie związny z warstwą persystencji / metodą pobierania / utrwalania stanu.

jak wyżej, rzeźba w g...... rozsmarowywanie jakiejkolweik logiki biznesowego poza Model to masakra.

Proszę podesłać "use case" a ja wyjaśnię wygląda realizacja na "dobrych" ORM ..Ten post został edytowany przez Autora dnia 22.10.13 o godzinie 20:20

Temat: Event sourcing

Jakub W.:

jeżeli zdefiniujemy wzorzec Fabryka jako "wiedza biznesowa o tworzeniu nowych agregatów biznesowych", to "odtworzenie" ich z "persystencji" nie jest ich wytwarzaniem, przywoływanie to niewidzialna (co sam zauwazyłeś) rola repozytorium

W celu uniknięcia nieporozumień proszę o przykład :)

przykład czego, fabryki w ORM? Ja nie potrafię :) ale jeżeli uznamy, że ORM to implementacja obiektowego repozytorium na relacyjnej bazie to o co pytasz?

ORM to dosłownie "object to relational mapping" a nie odwrotnie,

Nazwa generalnie jest głupia bo object może mieć dość dowolne (wzorzec dekoratora) relacje z reszta systemu podczas gdy.. a nieważne.

dekorator jako wzorzec nie jest chyba używany w obszarze modelu dziedziny, raczej widoki...

ORM to wyłącznie implementacja repozytorium a nie logika,

nom .. a fabryki ?

czyli uważasz, że wzorzec projektowy repozytorium ma także funkcję kreacyjną?

Myślałem, że jeśli ORM dostarczający logikę biznesową jest senem wariata ... :)

podaj może swoja definicję 'wzorca repozytorium"... ja korzystam z opisu wzorca np. takiego:





źr. http://msdn.microsoft.com/en-us/library/ff649690.aspx

Proszę podesłać "use case" a ja wyjaśnię wygląda realizacja na "dobrych" ORM ..

to raczej ja poproszę o wyjaśnienie co ma Use Case do ORM (use case w rozumieniu UML)Ten post został edytowany przez Autora dnia 22.10.13 o godzinie 21:43

Temat: Event sourcing

Jakub W.:
BTW: Czym inspirujesz się pisząc takie rzeczy ? :) Serio, jestem tym zafascynowany. Przepisujesz "strumień myśli" czy raczej dokładnie analizujesz to o czym i jak piszesz ?

Dobra, to szczerze przedstawię Ci, jak ja ten tekst rozumiem.
Udi wyraził w nim spostrzeżenie, że CQRS wpadł w kanon over-enginieringu, czyli jest często stosowany tam gdzie sprawdziła by się też prostsza architektura.
Tak samo jak ludzie stosują podejście DDD do aplikacji, które mają znikomą ilość logiki biznesowej, tak samo inny stosują CQRS do aplikacji, która posiada płytkie i proste agregaty. To wszystko jest przerostem formy nad treścią i jedyne co robi to przyrost kosztów.
Tylko czy to, że duża część osób (Udi stwierdził, że nawet większość) postępuje w ten sposób, natychmiastowo czyni CQRS czymś "złym" ? Ponadto zauważ, że "should avoid most of time", nie określa jednoznacznie, że jak zastosujesz to Ci się system wyłoży i CQRS jest złe. Tylko raczej wskazuje, że w większości przypadków, nie jest to rozwiązanie optymalne.
Te sprawy nie są zero-jedynkowe, każda aplikacja ma swoje problemy i zgodnie z tym co mówiłeś sam wcześniej, trzeba stosować rozwiązanie do problemu. Nawet jeśli dane rozwiązania nadają się do zastosowania w małej ilości przypadków, wcale nie neguje ich przydatności.
Nie ma tutaj żadnej sprzeczności, jestem wręcz zaskoczony, że jeden z autorów rozwiązania jest na tyle odważny, by tak otwarcie i stanowczo krytykować jego niepoprawne użycie. Gdyby jak Ty to mówisz "wymyślił sobie" ten wzorzec, to nie dążył by do jego krytycznej oceny, tylko forsował by go wszędzie gdzie się da.

To twórcy oprogramowania intencjonalnie tworzyli "overly-complex software" ?
Myślę, że nikt nie używał tego "na siłę"...

Oj to byś się zdziwił. Domeną mało doświadczonych architektów jest przerost inżynierii. Taki człowiek znajduje "super-hiper" najnowsze wzorce, i przekonany o ich wyższości, forsuje je w miejscach, gdzie nie są w ogóle potrzebne. Krytyka i samo-refleksja przychodzi z doświadczeniem i zwykle po spartoleniu już czegoś po drodze.
DDD i CQRS (ES z pewnością też) są dobre w danych zastosowaniach, żaden z nich nie jest uniwersalny i też żaden z nich nie powinien być oceniany przez pryzmat ich niepoprawnego zastosowania.

Problemy - dodatkowa pisanina.
Spostrzeżenia - ES rozwiązało problemy których nie przewidzieliśmy
Ciekawostki - klient najpierw bardzo opierał się przed pomysłem, a później był wdzięczny za to, że go wdrożyliśmy.

Powiem Ci wszystko o ES... ;)

Sorry, nie mam zamiaru uczestniczyć w niepoważnej dyskusji, czasami ma wrażenie że pomyliłeś ten temat z "Hyde-park".

Temat: Event sourcing

Zgadzam się, że

Domeną mało doświadczonych architektów jest przerost inżynierii. Taki człowiek znajduje "super-hiper" najnowsze wzorce, i przekonany o ich wyższości, forsuje je w miejscach, gdzie nie są w ogóle potrzebne. Krytyka i samo-refleksja przychodzi z doświadczeniem i zwykle po spartoleniu już czegoś po drodze.
DDD i CQRS (ES z pewnością też) są dobre w danych zastosowaniach, żaden z nich nie jest uniwersalny i też żaden z nich nie powinien być oceniany przez pryzmat ich niepoprawnego zastosowania.

dodam, że taka samą wada jest uznanie, że "baza RDBMS i model relacyjny może wszystko" bo w zmiennym środowisku może niestety bardzo mało...

moim zdaniem warto pamiętać, że:
- CQRS to sposób na zwiększenie wydajności konkretnych usług a nie "aplikacji" jako całości (dlatego jest "ukrywane" za interfejsem do usprawnianego komponentu realizującego konkretną usługę)
- DDD to raczej pewna filozofia, podejście do modelowania dziedziny z określonymi korzyściami wynikającymi z "symulacyjnego" podejścia do analizy, modelowania i implementacji.

w przypadku ES, z mojej strony: w modelowaniu dziedziny nie widzę miejsca na to, a innych komponentów nie modeluje więc nie mam zdania :)

Uwaga do Jakuba: miej pokorę do tego co inni osiągnęli bo byc może po protu nie miałeś okazji zetknąć się z jakimś problemem, a to, że nie miałeś takiego nie znaczy że takie nie istnieją..

Na obronę Jakuba: 90% treści w sieci to bełkot i pseudowiedza, więc ma dużo racji że jest ostrożny :)

Udi Dahan, podpadł mi już kilka razy (zdarza mu się "normalizować" model domeny) i także mam rezerwę do jego bloga, co nie zmienia faktu, że to jeden z ciekawszych blogów :), i chyba jest wyżartym programista i jednak technokratą kodowym.... (dla taki technokrata to ktoś wyznający zasadę wyższości kodu nad rzeczywistością).

(a Fowler to chyba zaczął się nudzić :)) Ten post został edytowany przez Autora dnia 23.10.13 o godzinie 14:15

Temat: Event sourcing

Jakub W.:

Niekoniecznie. Fabryka jest odpowiedzialna jest za tworzenie obiektów biznesowych.
W przypadku "dobrego" ORM (np. Lightspeed formy Mindscape) obiekty biznesowe są tworzone przez ORM... Pewnie to będzie wymagać dodatkowego komentarza ;)

Jarosław Ż.:

jeżeli zdefiniujemy wzorzec Fabryka jako "wiedza biznesowa o tworzeniu nowych agregatów biznesowych", to "odtworzenie" ich z "persystencji" nie jest ich wytwarzaniem, przywoływanie to niewidzialna (co sam zauwazyłeś) rola repozytorium

To jest dość często poruszany dylemat. Było na ten temat wiele dyskusji, konkluzja jest mniej więcej taka:

Fabryka w kanonie DDD jest tylko i wyłącznie enkapsulacją logiki domenowej, która dotyczy stworzenia NOWEJ instancji agregatu na początku jego istnienia. Wiem, że bardzo często odnosi się wrażenie, że fabryka powinna być też odpowiedzialna za składanie już istniejących ageregatów z danych zawartych w bazie danych.
W rzeczywistości za te "składanie" odpowiada infrastruktura repozytorium, która nie ma nic wspólnego z domenową fabryką. Zadaniem tej infrastruktury jest transparentne odtworzenie agregatu, bez udziału logiki domenowej.

Co ciekawe, w większości przypadków naszą fabryką może być jedna prosta metoda wytwórcza, która nie jest oddzielną klasą, ale odpowiada za dokładnie to samo i jest to rozwiązanie jak najbardziej poprawne.

Temat: Event sourcing

Marcin M.:
Fabryka w kanonie DDD jest tylko i wyłącznie enkapsulacją logiki domenowej, która dotyczy stworzenia NOWEJ instancji agregatu na początku jego istnienia. Wiem, że bardzo często odnosi się wrażenie, że fabryka powinna być też odpowiedzialna za składanie już istniejących ageregatów z danych zawartych w bazie danych.
W rzeczywistości za te "składanie" odpowiada infrastruktura repozytorium, która nie ma nic wspólnego z domenową fabryką. Zadaniem tej infrastruktury jest transparentne odtworzenie agregatu, bez udziału logiki domenowej.

Co ciekawe, w większości przypadków naszą fabryką może być jedna prosta metoda wytwórcza, która nie jest oddzielną klasą, ale odpowiada za dokładnie to samo i jest to rozwiązanie jak najbardziej poprawne.

tak :), dodam, ze fabryka z projektu DDD może być implementowana jako: Fabryka abstrakcyjna, metoda wytwórcza czy prototyp, byle z wyczuciem :), z mojej perspektywy (jestem 'przed implementacją" mało mnie obchodzi to jak nazwiemy wyciąganie obiektów z bazy, byle nie psuło logiki całości a konkretnie jestem organicznie uczulony na implementacje, które ignorują separację obiektów (komponentów): nie znoszę jak mi ktoś "pod spodem" funduje wielkiego ORM i normalizacje danych "bo tak się bazy projektuje", jak tylko to namierzam to funduje wykonawcy testy na separacje komponentów i refaktoring na koszt własny :) Ten post został edytowany przez Autora dnia 23.10.13 o godzinie 14:42

Temat: Event sourcing

Jarosław Ż.:
w przypadku ES, z mojej strony: w modelowaniu dziedziny nie widzę miejsca na to, a innych komponentów nie modeluje więc nie mam zdania :)

CQRS też nie ma wpływu na modelowanie domeny, a jednak uznałeś go za temat interesujący i warty opisania :) CQRS (tak samo jak ES) to wzorzec implementacji, który dostarcza możliwości techniczne. Ja tu nie widzę jakiejś kardynalnej różnicy.

Udi Dahan, podpadł mi już kilka razy (zdarza mu się "normalizować" model domeny)

Tak też z innej beczki... chciałbym zapytać się Ciebie, co masz dokładnie na myśli mówiąc o "nadmiernej normalizacji danych biznesowych" ? Powtarzasz ten stwierdzenie przy wielu okazjach i zdaje mi się że nie do końca załapuje o co Ci chodzi.

Temat: Event sourcing

Marcin M.:

Jarosław Ż.:
w przypadku ES, z mojej strony: w modelowaniu dziedziny nie widzę miejsca na to, a innych komponentów nie modeluje więc nie mam zdania :)

CQRS też nie ma wpływu na modelowanie domeny, a jednak uznałeś go za temat interesujący i warty opisania :) CQRS (tak samo jak ES) to wzorzec implementacji, który dostarcza możliwości techniczne. Ja tu nie widzę jakiejś kardynalnej różnicy.

CQRS ma ogromny wpływ na model dziedziny bo to ja projektuję w komponencie dziedzinowym "zeszycik na szybkie oferty" obok pełnego agregatu i więcej: to jest wymaganie (taka konstrukcja) dla developera. Moje przykładowe diagramy w linkowanym moim artykule to elementy modelu dziedziny.

Udi Dahan, podpadł mi już kilka razy (zdarza mu się "normalizować" model domeny)

Tak też z innej beczki... chciałbym zapytać się Ciebie, co masz dokładnie na myśli mówiąc o "nadmiernej normalizacji danych biznesowych" ? Powtarzasz ten stwierdzenie przy wielu okazjach i zdaje mi się że nie do końca załapuje o co Ci chodzi.

normalizacja tu usuwanie redundancji w modelu dziedziny, to skutkuje jego totalną niepodzielnoscią czyli zalety w rodzaju "separacja obiektów" wzięły w łeb...

Temat: Event sourcing

Jarosław Ż.:
normalizacja tu usuwanie redundancji w modelu dziedziny, to skutkuje jego totalną niepodzielnoscią czyli zalety w rodzaju "separacja obiektów" wzięły w łeb...

Tutaj podpisuje się obiema rękami : ] Model ma odwzorowywać rzeczywistość i jeśli redundancja występuje w realu, to ma tez być w modelu.

CQRS ma ogromny wpływ na model dziedziny bo to ja projektuję w komponencie dziedzinowym "zeszycik na szybkie oferty" obok pełnego agregatu i więcej: to jest wymaganie (taka konstrukcja) dla developera. Moje przykładowe diagramy w linkowanym moim artykule to elementy modelu dziedziny.

Aha, no to już wiem jaka jest główna różnica w naszym postrzeganiu CQRS, które powodowało nieporozumienia ciągnące się przez wiele tematów. Ta kwestia też zahacza o wcześniejsze niezrozumienie z danymi audytowymi...

Rozważmy prostą domenę z ofertami i klientami:
1. W modelu domeny będą dwa agregaty: Oferta i Klient, w czym będzie asocjacja klienta z ofertą. Ten model jest wyrażony całkowicie w języku domenowym (podstawowy warunek DDD) i powinien być zrozumiały dla eksperta domenowego.
2. Architekt spogląda na model domeny, wybiera technologię (powiedzmy ORM) i implementuje domenę, tak by obiekty w języku programowania odpowiadały agregatom z modelu.
3. Gui aplikacji zestawia klientów i oferty, w cele wygodnego podglądu. Architekt robi testy wydajnościowe i dochodzi do wniosku, że zestawienie jest za wolne, bo za każdym razem musimy joinować oferty i klientów. Decyduje się na użycie CQRS.
4. Powstaje obiekt "ZeszycikNaSzybkieOferty", który zawiera od razu dane z obu agregatów. Cel wydajnościowy został osiągnięty.

Czy serio sądzisz, że obiekt "ZeszycikNaSzybkieOferty", powinien być przewidziany i od razu skonstruowany na poziomie modelingu (nr.1) ? Co powie ekspert domenowy, jak popatrzy na model, który zawiera takie obiekty ? Czy "kopiowanie" danych z agregatów do obiektu CQRS to jakaś domenowa operacja, czy typowo techniczna ?

Zgodnie z całą moją najnowszą wiedzą o CQRS: obiekty CQRS dostosowane do odczytu, są typowo sztucznymi, technicznymi obiektami, które nie istnieją w rzeczywistości. Zadaniem analityka/modelarza jest stworzyć model domeny dobrze odwzorujący rzeczywistość. Zadaniem architekta jest dołożenie infrastruktury, która będzie spełniała wymagania wydajnościowe i CQRS (jeśli zostanie użyty) jest częścią tej infrastruktury.

Temat: Event sourcing

Marcin M.:

Jakub W.:
BTW: Czym inspirujesz się pisząc takie rzeczy ? :) Serio, jestem tym zafascynowany. Przepisujesz "strumień myśli" czy raczej dokładnie analizujesz to o czym i jak piszesz ?

Dobra, to szczerze przedstawię Ci, jak ja ten tekst rozumiem.

Jedziesz ;)

Udi wyraził w nim spostrzeżenie, że CQRS wpadł w kanon over-enginieringu, czyli jest często stosowany tam gdzie sprawdziła by się też prostsza architektura.
Tak samo jak ludzie stosują podejście DDD do aplikacji, które mają znikomą ilość logiki biznesowej, tak samo inny stosują CQRS do aplikacji, która posiada płytkie i proste agregaty. To wszystko jest przerostem formy nad treścią i jedyne co robi to przyrost kosztów.

Ok, ale z tego wynika (So, when should you avoid CQRS? The answer is most of the time.), że CQRS powinno się stosować tylko w pewnych szczególnych sytuacjach / typach projektów.

Pomijając fakt, że Udi najwyraźniej nie opisał w jakich sytuacjach CQRS jest użyteczne (to samo dotyczy ES);

Dlaczego następny "z cyklu" artykuł ma tytuł "Why you should be using CQRS almost everywhere…" ( http://www.udidahan.com/2011/10/02/why-you-should-be-u... ) ?

Tylko czy to, że duża część osób (Udi stwierdził, że nawet większość) postępuje w ten sposób, natychmiastowo czyni CQRS czymś "złym" ?

Chwila ... to już udowodniono, że jest czymś dobrym ? :)
Chodzi o to, że najwyraźniej nie wiadomo (podobnie jak w przypadku ES) czym jest i jak stosować CQRS.

Z resztą sam Udi stwierdził - ludzie nie rozumieją jego pomysłu... w szczególnym przypadku - Ty "almost for sure" też go nie rozumiesz.
Wypowiadasz się nt. idei która jest niewiadomą. Daj znać jeśli się mylę.

Pytanie: co konkretnego chcesz przekazać w poniższym tekście ?
Dla mnie poniższe to tekst bez treści...

Ponadto zauważ, że "should avoid most of time", nie określa jednoznacznie,
że jak zastosujesz to Ci się system wyłoży i CQRS jest złe. Tylko raczej wskazuje, że w większości przypadków, nie jest to rozwiązanie optymalne.
Te sprawy nie są zero-jedynkowe, każda aplikacja ma swoje problemy i zgodnie z tym co mówiłeś sam wcześniej, trzeba stosować rozwiązanie do problemu. Nawet jeśli dane rozwiązania nadają się do zastosowania w małej ilości przypadków, wcale nie neguje ich przydatności.
Nie ma tutaj żadnej sprzeczności, jestem wręcz zaskoczony, że jeden z autorów rozwiązania jest na tyle odważny, by tak otwarcie i stanowczo krytykować jego niepoprawne użycie. Gdyby jak Ty to mówisz "wymyślił sobie" ten wzorzec, to nie dążył by do jego krytycznej oceny, tylko forsował by go wszędzie gdzie się da.

To twórcy oprogramowania intencjonalnie tworzyli "overly-complex software" ?
Myślę, że nikt nie używał tego "na siłę"...

Oj to byś się zdziwił.
Domeną mało doświadczonych architektów jest przerost inżynierii. Taki człowiek znajduje "super-hiper" najnowsze wzorce, i przekonany o ich wyższości, forsuje je w miejscach, gdzie nie są w ogóle potrzebne. Krytyka i samo-refleksja przychodzi z doświadczeniem i zwykle po spartoleniu już czegoś po drodze.
DDD i CQRS (ES z pewnością też) są dobre w danych zastosowaniach,
żaden z nich nie jest uniwersalny i też żaden z nich nie powinien być oceniany przez pryzmat ich niepoprawnego zastosowania.

Celne.
Proszę o źródła. Idea wydaje się genialna, ale wolę się upewnić, że na czymś bazuje.

"CQRS (ES z pewnością też) są dobre w danych " .. tylko nie wiadomo w jakich. Dzizas ...

Problemy - dodatkowa pisanina.
Spostrzeżenia - ES rozwiązało problemy których nie przewidzieliśmy
Ciekawostki - klient najpierw bardzo opierał się przed pomysłem, a później był wdzięczny za to, że go wdrożyliśmy.

Powiem Ci wszystko o ES... ;)

Sorry, nie mam zamiaru uczestniczyć w niepoważnej dyskusji,

sam ją zacząłeś (niepoważną dyskusję)

czasami ma wrażenie że pomyliłeś ten temat z "Hyde-park".

naturalnie. dlatego właśnie rozpisuję się na temat rzeczy które "nie wiadomo do czego służą, ale zapewne do czegoś służą". :)

Na tym polega hyde-park.

A tak na serio - jak już pisałem - jeśli nie masz konkretnego problemu nie znajdziesz konkretnego rozwiązania. W tym momencie mogę wmówić Ci (no ja akurat nie ale jakiś "wyjadacz" to już tak) wszystko, bo jedynym ograniczeniem będzie twoja wyobraźnia, a nie przydatność / użyteczność.Ten post został edytowany przez Autora dnia 24.10.13 o godzinie 09:51

Temat: Event sourcing

Jarosław Ż.:

Jakub W.:

jeżeli zdefiniujemy wzorzec Fabryka jako "wiedza biznesowa o tworzeniu nowych agregatów biznesowych", to "odtworzenie" ich z "persystencji" nie jest ich wytwarzaniem, przywoływanie to niewidzialna (co sam zauwazyłeś) rola repozytorium

W celu uniknięcia nieporozumień proszę o przykład :)

przykład czego, fabryki w ORM? Ja nie potrafię :)

Nie. Proszę o opis / przykład tego "co fabryka robi".

ORM to wyłącznie implementacja repozytorium a nie logika,

nom .. a fabryki ?

czyli uważasz, że wzorzec projektowy repozytorium ma także funkcję kreacyjną?

Nie. chcę tylko wiedzieć za co odpowiadają (jaką maja funkcję) "fabryki".

Myślałem, że jeśli ORM dostarczający logikę biznesową jest senem wariata ... :)

podaj może swoja definicję 'wzorca repozytorium"... ja korzystam z opisu wzorca np. takiego:





źr. http://msdn.microsoft.com/en-us/library/ff649690.aspx

Czy w wzorcu repozytorium chodzi o to, żeby "You want to maximize the amount of code that can be tested with automation and to isolate the data layer to support unit testing & shit " ? :)

Chciałem jedyne powiedzieć, że ORM nie dostarcza logiki biznesowej sam z siebie.

Proszę podesłać "use case" a ja wyjaśnię wygląda realizacja na "dobrych" ORM ..

to raczej ja poproszę o wyjaśnienie co ma Use Case do ORM (use case w rozumieniu UML)

Dobry ORM pozwala na transparentne zachowanie stanu (w konsekwencji - efektów wywołania UC) aplikacjiTen post został edytowany przez Autora dnia 23.10.13 o godzinie 19:43

Temat: Event sourcing

Jakub W.:
Nie. Proszę o opis / przykład tego "co fabryka robi".

napisałem: tworzy (nie odtwarza) nowe złożone agregaty

Nie. chcę tylko wiedzieć za co odpowiadają (jaką maja funkcję) "fabryki".

jak wyżej

Czy w wzorcu repozytorium chodzi o to, żeby "You want to maximize the amount of code that can be tested with automation and to isolate the data layer to support unit testing & shit " ? :)

wzorzec repozytorium to enkapsulacja utrwalania, czyli na poziomie projektu obiektowego, jest klasa odpowiadająca za przechowywanie z operacja "weź to i zachowaj na później", nie intersuje nas jak to się stanie (baza RDBMS, plik csv, inne warianty)

Chciałem jedyne powiedzieć, że ORM nie dostarcza logiki biznesowej sam z siebie.

a jak?

Dobry ORM pozwala na transparentne zachowanie stanu (w konsekwencji - efektów wywołania UC) aplikacji

czym jest tu "stan"? Bo to chyba pojęcie niskopoziomowe, na poziomie modelu dziedziny można mówić raczej o "atrybutach".. to jest prawie to samo ale prawie robi różnicę :)

Temat: Event sourcing

Marcin M.:
Czy serio sądzisz, że obiekt "ZeszycikNaSzybkieOferty", powinien być przewidziany i od razu skonstruowany na poziomie modelingu (nr.1) ? Co powie ekspert domenowy, jak popatrzy na model, który zawiera takie obiekty ? Czy "kopiowanie" danych z agregatów do obiektu CQRS to jakaś domenowa operacja, czy typowo techniczna ?

tak :), bo jak badam to co robi np. magazynier, to widze, ze wypasioną szufladę z kartami produktów i podręczny zeszycik z cennikiem, modelując dziedzinę odtwarzam oba te "rejestry" :) bo to ma głęboki sens "dla wydajnosci magazyniera", czasamu CQRS "dodaję" później lub faktycznie robi to architekt, a czasami wale od razu bo doświadczenie uczy, że bez tego będzie kicha

Zgodnie z całą moją najnowszą wiedzą o CQRS: obiekty CQRS dostosowane do odczytu, są typowo sztucznymi, technicznymi obiektami, które nie istnieją w rzeczywistości.

patrz powyższy przykład magazynier: one często własnie istnieją, tak prawdę mowiąc korzystałem z tej konstrukcji znacznie wcześniej niż spotkałem wzorzec CRQR i jego nazwę

Zadaniem analityka/modelarza jest stworzyć model domeny dobrze odwzorujący rzeczywistość.

mamy zeszycik :)

Zadaniem architekta jest dołożenie infrastruktury, która będzie spełniała wymagania wydajnościowe i CQRS (jeśli zostanie użyty) jest częścią tej infrastruktury.

jak widzisz nie koniecznie, po drugie: w jakim komponencie umieścisz dodatkowy "zeszycik", jeżeli nie w modelu domeny?

Temat: Event sourcing

Jarosław Ż.:
tak :), bo jak badam to co robi np. magazynier, to widze, ze wypasioną szufladę z kartami produktów i podręczny zeszycik z cennikiem, modelując dziedzinę odtwarzam oba te "rejestry" :) bo to ma głęboki sens "dla wydajnosci magazyniera", czasamu CQRS "dodaję" później lub faktycznie robi to architekt, a czasami wale od razu bo doświadczenie uczy, że bez tego będzie kicha

patrz powyższy przykład magazynier: one często własnie istnieją, tak prawdę mowiąc korzystałem z tej konstrukcji znacznie wcześniej niż spotkałem wzorzec CRQR i jego nazwę

W pewnym sensie masz rację : ) Można rzeczywiście znaleźć w biznesie przykłady takich uproszczeń, w celu prezentowania danych.

Jednak ja nie szukał bym takich obiektów w biznesie, z kilku powodów:
1. Widoki, raporty, podsumowania, audyty, uproszczenia, zestawienia to wszystko może się zmieniać zależnie od humoru klienta(lub od magazyniera, który stwierdził, że wpisze do dzienniczka jakiego koloru są paczki w magazynie :p). Oczywiście możesz znaleźć to w biznesie, pytanie czy to powinno wejść do rdzenia naszej abstrakcji biznesu ? Moim zdaniem nie, domena się nie zmienia.
2. Domena powinna być możliwie prosta, jeśli zaczniemy do jednego worka wrzucać widoki, to może się okazać, że nasz core domain utonie w oceanie raportopodobnych rzeczy :) Trzeba pamiętać, że domena to abstrakcja rzeczywistości, która powinno zawierać tylko byty najistotniejsze dla biznesu.
3. Wkraczamy tutaj na grunt programistów i architektów. CQRS wprowadza skomplikowanie i zgodnie z królem wszystkich zasad (KISS!) nie robimy, czegoś co nie jest potrzebne. Dlatego moim zdaniem najpierw należy zawsze przetestować wydajnościowo odczyt na ciężkich agregatach i optymalizować tylko, jeśli jest to konieczne.

Rzeczywiście temat jest śliski i subiektywny więc myślę, że nie ma większego sensu go dobijać. Przedstawiłem swój punkt widzenia, Ty przedstawiłeś swój, moim zdaniem się rozumiemy. Najważniejsze jest to, że ta rozmowa przyniosła (przynajmniej dla mnie, mam nadzieję, że dla Ciebie też) jakąś wartość dodaną :)

Zadaniem architekta jest dołożenie infrastruktury, która będzie spełniała wymagania wydajnościowe i CQRS (jeśli zostanie użyty) jest częścią tej infrastruktury.

jak widzisz nie koniecznie, po drugie: w jakim komponencie umieścisz dodatkowy "zeszycik", jeżeli nie w modelu domeny?

Dla Ciebie to będzie kontroler, dla mnie raczej serwis aplikacyjny. W gruncie rzeczy robimy sztuczną encję poza domeną, która napełniana jest danymi używając dowolnego mechanizmu. Może to być replikacja na poziomie bazy danych, może być przechwycenie wywołania repozytorium domenowego, lub jak to się dzieje w ES - event biznesowy. Potem modyfikujemy implementacje query interface, tak by używała tej encji zamiast agregatów i to wszystko. Wiem, to brzmi technokratycznie, ale i tak wole to niż pchanie wszystkiego do domeny.

Temat: Event sourcing

Jarosław Ż.:

Jakub W.:
Nie. Proszę o opis / przykład tego "co fabryka robi".

napisałem: tworzy (nie odtwarza) nowe złożone agregaty

... dlaczego "tworzyć" nie może konstruktor obiektu biznesowego ?

Czy w wzorcu repozytorium chodzi o to, żeby "You want to maximize the amount of code that can be tested with automation and to isolate the data layer to support unit testing & shit " ? :)

wzorzec repozytorium to enkapsulacja utrwalania, czyli na poziomie projektu obiektowego, jest klasa odpowiadająca za przechowywanie z operacja "weź to i zachowaj na później", nie intersuje nas jak to się stanie (baza RDBMS, plik csv, inne warianty)

Lighspeed "automatycznie" (nie trzeba tworzyć specjalnych klas, a jedynie wywołać "SaveChanges") utrwala stan... Nie, to nie jest polemika; chcę jedynie pokazać, że pewne rzeczy, przy istniejących rozwiązaniach, można robić lepiej - w szczególności, że przy -dobrym (który ma pewne funkcjojalności)- ORM nie trzeba stosować CQRS (czymkolwiek jest)...

Dobry ORM pozwala na transparentne zachowanie stanu (w konsekwencji - efektów wywołania UC) aplikacji

czym jest tu "stan"? Bo to chyba pojęcie niskopoziomowe, na poziomie modelu dziedziny można mówić raczej o "atrybutach".. to jest prawie to samo ale prawie robi różnicę :)

Wartości atrybutów / struktury agregatów... Stan :)Ten post został edytowany przez Autora dnia 24.10.13 o godzinie 10:07

Temat: Event sourcing

Jakub W.:

Jarosław Ż.:

Jakub W.:
Nie. Proszę o opis / przykład tego "co fabryka robi".

napisałem: tworzy (nie odtwarza) nowe złożone agregaty

... dlaczego "tworzyć" nie może konstruktor obiektu biznesowego ?

bo dobra praktyka jest to, że np. fakturę VAT wystawia fakturzysta a nie faktura, logika tworzenia dokumentu prawie nigdy nie jest logika dokumentu wytworzonego (do korzystania z faktury nie potrzebna jest wiedza o tym jak powstała), dlatego też dwie odpwoedzialnosći warto rozdzilić, korzyść: mamy klasę FakturaVat i klasę TwórcaFakturVAT, zmiana pzrepisów będzie wymagała wyałcznie zmian w klasie TwórcaFakturVAT kasa FatkturaVat (i cała kolekcja obiektów) nie wymaga zmian.

wiem, ze każdy jezyk onbiektowy ma dla klasy domyślna operacje new() ale to nie jest dobra praktyka

wzorzec repozytorium to enkapsulacja utrwalania, czyli na poziomie projektu obiektowego, jest klasa odpowiadająca za przechowywanie z operacja "weź to i zachowaj na później", nie intersuje nas jak to się stanie (baza RDBMS, plik csv, inne warianty)

Lighspeed "automatycznie" (nie trzeba tworzyć specjalnych klas, a jedynie wywołać "SaveChanges") utrwala stan... Nie, to nie jest polemika; chcę jedynie pokazać, że pewne rzeczy, przy istniejących rozwiązaniach, można robić lepiej - w szczególności, że przy -dobrym (który ma pewne funkcjojalności)- ORM nie trzeba stosować CQRS (czymkolwiek jest)...

problem w tym, że te "pewne rzeczy" same z siebie stają się niezrozumiałe, zauważ, że np. normalizacja bazy jest procesem stratnym, korzysć to oszczędnośc miejsca, wada: tracimy całą widze o danych źrdólwych (baza RDBS zawiera dane poztrebne do odtworzenia faktury ale nie zawiera informacji o tym jak wygląda faktura, musi to zrobić jakaś "funkcja".

Wyjęcie logiki biznesowej (np. tworzenie agregatów) poza Model niszczy spójność tej logiki, dobry projekt (zarządzamy nie tylko tym, że działa, ale tym, że jest na swój sposób samodokumentujący się bo to jedna z zalet DDD) to taki, w kórym "wyjęcie" logiki biznesowej (komponentu Model) nie powoduje żadnej straty dla funckjonalości. Formalnie więc mogę zmienić środowisko implementacji Modelu bez szkody dla Modelu.

Dobry ORM pozwala na transparentne zachowanie stanu (w konsekwencji - efektów wywołania UC) aplikacji

czym jest tu "stan"? Bo to chyba pojęcie niskopoziomowe, na poziomie modelu dziedziny można mówić raczej o "atrybutach".. to jest prawie to samo ale prawie robi różnicę :)

Wartości atrybutów / struktury agregatów... Stan :)

ok.... :)Ten post został edytowany przez Autora dnia 24.10.13 o godzinie 10:46

Temat: Event sourcing

Jarosław Ż.:

Jakub W.:

Jarosław Ż.:

Jakub W.:
Nie. Proszę o opis / przykład tego "co fabryka robi".

napisałem: tworzy (nie odtwarza) nowe złożone agregaty

... dlaczego "tworzyć" nie może konstruktor obiektu biznesowego ?

bo dobra praktyka jest to, że np. fakturę VAT wystawia fakturzysta a nie faktura, logika tworzenia dokumentu prawie nigdy nie jest logika dokumentu wytworzonego (do korzystania z faktury nie potrzebna jest wiedza o tym jak powstała), dlatego też dwie odpwoedzialnosći warto rozdzilić, korzyść: mamy klasę FakturaVat i klasę TwórcaFakturVAT, zmiana pzrepisów będzie wymagała wyałcznie zmian w klasie TwórcaFakturVAT kasa FatkturaVat (i cała kolekcja obiektów) nie wymaga zmian.

wiem, ze każdy jezyk onbiektowy ma dla klasy domyślna operacje new() ale to nie jest dobra praktyka

Dlaczego kod odpowiedzialny za tworzenie faktury nie może (nie powinien ?)
być w np. konstruktorze FatkturaVat (daneSprzedawcy, daneKupujacego,
data, pozycje) ?

Pomijając to, że konstruktor do tego służy, takie rozwiązanie ma te same zalety co dodanie klasy fabrykującej (kod
inicjalizacyjny w jednym miejscu) i żadnej z jej wad:
1. Dodatkowa klasa
2. Logika inicjalizacji obiektu klasy X jest poza klasą X
3. FatkturaVat musi zawierać publiczne settery (żeby fakaś fabryka
mogła ustalić stan obiektu ) z drugiej strony FatkturaVat nie powinna
zawierać publicznych setterów (bo faktur się nie zmienia).

wzorzec repozytorium to enkapsulacja utrwalania, czyli na poziomie projektu obiektowego, jest klasa odpowiadająca za przechowywanie z operacja "weź to i zachowaj na później", nie intersuje nas jak to się stanie (baza RDBMS, plik csv, inne warianty)

Lighspeed "automatycznie" (nie trzeba tworzyć specjalnych klas, a jedynie wywołać "SaveChanges") utrwala stan... Nie, to nie jest polemika; chcę jedynie pokazać, że pewne rzeczy, przy istniejących rozwiązaniach, można robić lepiej - w szczególności, że przy -dobrym (który ma pewne funkcjojalności)- ORM nie trzeba stosować CQRS (czymkolwiek jest)...

problem w tym, że te "pewne rzeczy" same z siebie stają się niezrozumiałe, zauważ, że np. normalizacja bazy jest procesem stratnym, korzysć to oszczędnośc miejsca,

Korzyści jest dużo więcej :)
http://en.wikipedia.org/wiki/Database_normalization#Ob...

wada: tracimy całą widze o danych źrdólwych (baza RDBS zawiera dane poztrebne do odtworzenia faktury ale nie zawiera informacji o tym jak wygląda faktura, musi to zrobić jakaś "funkcja".

To zawsze robi jakaś funkcja. Pytanie gdzie ta funkcja się znajduje (baza
danych / aplikacja) i kiedy jest wywoływana (tuż po dodaniu nowych danych
/ w trakcie pobierania danych).

Wyjęcie logiki biznesowej (np. tworzenie agregatów) poza Model niszczy spójność tej logiki,

A co jeśli agregaty są tworzone w konkretnych obiektach biznesowych, a nie w (dosłownie) bazie danych ?
Proszę sobie wyobrazić sytuację, kiedy do wykonania pewnego use case pobierane są tylko te dane, jakich dany obiekt biznesowy w danej sytuacji potrzebuje. To jest z jednej strony wydajne sprzętowo (pobieranie tylko potrzebnych danych) a z drugiej - programistyczne.

Temat: Event sourcing

Jakub W.:
Dlaczego kod odpowiedzialny za tworzenie faktury nie może (nie powinien ?)
być w np. konstruktorze FatkturaVat (daneSprzedawcy, daneKupujacego,
data, pozycje) ?

bo do operowania istniejącą fakturą, nie jest potrzebna skomplikowana umiejętność jej wytworzenia, po co mi po roku kilka tysięcy faktur każda z praktycznie zakazaną operacją new()??? skoro wystarczy, ze każda ma np. operacje print() i serializuj().

Pomijając to, że konstruktor do tego służy, takie rozwiązanie ma te same zalety co dodanie klasy fabrykującej (kod
inicjalizacyjny w jednym miejscu) i żadnej z jej wad:
1. Dodatkowa klasa

to nie jest wada

2. Logika inicjalizacji obiektu klasy X jest poza klasą X

próbujesz mnie przekonać, że każdy Polonez ma wozić w bagażniku całą fabrykę FSO?

3. FatkturaVat musi zawierać publiczne settery (żeby fakaś fabryka
mogła ustalić stan obiektu ) z drugiej strony FatkturaVat nie powinna
zawierać publicznych setterów (bo faktur się nie zmienia).

nie, faktura ma operację serializuj() (nie natywną a napisaną) do publikowania swoich publicznych danych, tak jak każde archiwum faktur na każde pytanie o dowolny fragment faktury odsyła zawsze jej kompletna kopię, co jest bardzo ekonomiczne (archiwum/faktura ma jedną operację a nie tyle ile różnych wartości na fakturze)

problem w tym, że te "pewne rzeczy" same z siebie stają się niezrozumiałe, zauważ, że np. normalizacja bazy jest procesem stratnym, korzysć to oszczędnośc miejsca,

Korzyści jest dużo więcej :)
http://en.wikipedia.org/wiki/Database_normalization#Ob...

po normalizacji nie oddzielisz już np. księgowości od magazynów jak sobie firma zafunduje dedykowany system zarządzania magazynem wysokiego składowania obsługujący MMki...

nie dalej jak rok temu jeden z moich klientów poległ troszkę finansowo z tego powodu: miął fajny ERP z dobrą FK, ale rozwój firmy wymusił zakup dużego WMS, niestety FK - pod nim baza znormalizowana - nie pozwolił tego oddzielić, został nie małym kosztem wymieniony na nowy...

wada: tracimy całą widze o danych źrdólwych (baza RDBS zawiera dane poztrebne do odtworzenia faktury ale nie zawiera informacji o tym jak wygląda faktura, musi to zrobić jakaś "funkcja".

To zawsze robi jakaś funkcja. Pytanie gdzie ta funkcja się znajduje (baza
danych / aplikacja) i kiedy jest wywoływana (tuż po dodaniu nowych danych
/ w trakcie pobierania danych).

od kiedy to baza danych sama sięga do logiki????

Wyjęcie logiki biznesowej (np. tworzenie agregatów) poza Model niszczy spójność tej logiki,

A co jeśli agregaty są tworzone w konkretnych obiektach biznesowych, a nie w (dosłownie) bazie danych ?

a co jeżeli mam napaprane? nic.... od tworzenia obiektów i agregatów są inne obiekty wyspecjalizowane w tworzeniu

Proszę sobie wyobrazić sytuację, kiedy do wykonania pewnego use case pobierane są tylko te dane, jakich dany obiekt biznesowy w danej sytuacji potrzebuje. To jest z jednej strony wydajne sprzętowo (pobieranie tylko potrzebnych danych) a z drugiej - programistyczne.

tego nie zrozumiałem...

Temat: Event sourcing

a tak poważnie to ja mam jeden bardzo skuteczny miernik jakości architektury: roczny koszt wprowadzania zmian jeżeli są zgłaszane co miesiąc, albo drugi, określ ile będzie kosztował nowy kolejny przypadek użycia mimo, że nie masz jego opisu...;)

Temat: Event sourcing

Jakub W.:
To jest z jednej strony wydajne

[...]

programistyczne.

akurat to mam bardzo głęboko gdzieś, interesuje mnie wyłącznie spełnianie wymagań przez produkt finalny ... :)

powiem więcej, to kluczowy argument za tym, by łączenie roli projektanta z programistą uznać za bardzo wysokie ryzyko dla projektu :) Ten post został edytowany przez Autora dnia 24.10.13 o godzinie 20:31