wielkie dzieki za wartosciowe materialy. prezentujac glos mniej doswiadczonych programistow prosilbym o troszke wolniejsze "skakanie" po plikach lub o udostepnianie omawianego kodu zeby mozna sie bylo zaglebic i na spokojnie przeanalizowac. pozdrawiam
Kodzik masz tutaj: github.com/PanNiebieski/CQRSWithCSharp10AndNET6 Z tym skakaniem to jest taki problem, że algorytmy YT oceniają także filmik po długości oglądanego materiału więc nie mogę lać wody albo zastanawiać się za długo, ale dzięki za opinie
Dzięki za materiał, oglądałem wszystkie twoje filmy - przydają się aby się rozwijać jako programista, a także do pracy (bo wiadomo - nie wszystkich tych nowinek można w projektach użyć). Szkoda, że tak mało subów masz bo materiały są naprawdę na poziomie - moim zdaniem jesteś polskim odpowiednikiem Nicka Chapsas'a.
Stary dzięki za komentarz. Ja jestem świadomy, że skoro mówię po polsku o programowaniu to patrząc na inne kanały programistyczne to 10.000 subów to będzie szklany sufit.
Dzięki, za wideo i wytłumaczenie tego nie łatwego tematu. Ja ostatnio dostałem kilka rzeczy do zrobienia w projekcie wykorzystującym CQRS oraz MediatR, szczerze powiedziawszy ciężko mi się tam odnaleźć, nadmienie, że jest to integrator z jednym z systemów Comarchowych. Pytanie jak najlepiej wejść w taki projekt, od czego zacząć jego poznawanie? jak Ty wchodzisz w nieznane "środowisko"? Jest jakiś przewodnik, po dziczy?
Świetny materiał, chociaż nie łatwy. Dlatego mam kilka pytań :) - można gdzieś zobaczyć kod źródłowy przykładu by sobie lepiej to układać? - będzie coś więcej o tym jak robić sam event storming ? - no i nie za bardzo zrozumiałem jak zrobić by w pewnym etapie procesu, zrobić tak że wykonanie komendy zostanie wykonane dopiero po zajściu x zdarzeń. Np dokonujemy jakiejś akcji która wymaga potwierdzenia kogoś innego i nie wiemy kiedy to nastąpi?
Dzięki za to Czarku. Masz dar do tłumaczenia trudnych koncepcji w ciekawy sposób. Potrafisz wejść w głowę odbiorcy. Pewnie nad tym pracujesz, ale możesz podjąć wysiłek nad wymową po polsku (łykanie głosek) i angielsku (nieprawidłowa wymowa). Pewnie mogłoby to jeszcze bardziej podnieść jakość Twoich materiałów. Cieszę się, że jest ktoś taki jak Ty. Dałem suba, bo oglądałem listę Twoich nagrań i prawie wszystkie są na mojej liście "To learn...".
ua-cam.com/video/h60e8sXJyX8/v-deo.html Jesteś pewien, że źle napisana aplikacja to taka, gdzie odczyt coś zmienia? - np. counter wyświetleń (patrz UA-cam). Oczywiście, możemy powiedzieć, że odczyt nie zmienia nic w stanie aplikacji, jest to oddzielny proces. Natomiast odczyt jest jego wyzwalaczem i użytkownik nie robi oddzielnego "commanda" aby podbić licznik. Odczyt też jest np. wykorzystywany przy profilowaniu, zbieranie danych na potrzeby dostarczania odpowiednich treści, a jest to wywoływane jedynie odczytem użytkownika.
W tej filozofii, jeśli odczyt danych z jakiegoś powodu coś jeszcze modyfikuje to nie jest to tak naprawdę odczyt. Poruszyłeś też inną kwestię związaną z CQRS. Przykładowo Command nie powinien niczego zwracać (ja akurat nie trzymam się tej zasady zawsze). Co znaczy, że po modyfikacji, czyli zrobienia Command trzeba zrobić Query. Stąd pojawiają się takie pytania,a po co to dzielić w ogóle, kiedy muszę wysłać dwa żądania do serwera. Jednakże bez CQRS właściwie nie można moim zdaniem tworzyć oprogramowania gdzie są zdarzenia , a potem różne wzorce związane z mikroserwisami.
@@CezaryWalenciuk chyba brakuje tu definicji do jakiego poziomu schodzimy z CQRSem (front, api, serwisy, orm, db) i co oznacza "coś zwrócić" i "do kogo zwrócić" oraz "kto wywołuje proces". Nie wiem czy dobrze rozumiem, sugerujesz, że w przypadku z licznikiem YT, po requesta(get - querry) przez użytkownika (aktora) i pobraniu treści w postaci wideo. Dalej użytkownik (aktor) - wykonuje ręcznie/automatycznie request (command) o podbicie licznika? czuję, że tu byłyby dziury gdyby użytkownik sterował/wywoływał proces zarządzania licznikiem(inkrementacją). Ale do sprawdzenia. Trochę dziwi mnie generalizowanie, że "Command nie powinien niczego zwracać", Przy tworzeniu RESTowego api zawsze będziesz działał w komunikacji synchronicznej, mimo, że pod spodem procesy są obsługiwane asynchronicznie. I Command jak i Querry zawsze coś zwracają do klienta - response np. kod http (created/accepted ect.), można powiedzieć "nie zwracam na to uwagi" ale to dalej zwraca informację - czy to oznacza, że implementacja CQRS nie może opierać się na RESTowym API ponieważ respons wraca do klienta/aktora? Oczywiście tu się jeszcze wkrada temat np. kolejkowania, podejścia fire and forget - ale to za chwilę.
Bardzo pomocny film, dzięki!
Twój film naprawdę dobrze tłumaczy ten nie łatwy temat i pozwala odnaleźć drogę innym
wielkie dzieki za wartosciowe materialy. prezentujac glos mniej doswiadczonych programistow prosilbym o troszke wolniejsze "skakanie" po plikach lub o udostepnianie omawianego kodu zeby mozna sie bylo zaglebic i na spokojnie przeanalizowac. pozdrawiam
Kodzik masz tutaj: github.com/PanNiebieski/CQRSWithCSharp10AndNET6
Z tym skakaniem to jest taki problem, że algorytmy YT oceniają także filmik po długości oglądanego materiału więc nie mogę lać wody albo zastanawiać się za długo, ale dzięki za opinie
@@CezaryWalenciuk dziekuje
Super wytłumaczone, dzięki :)
Super to wyjaśniłeś! DZIĘKI ŻE JESTES!!
Super materiał, wytłumaczony temat w prosty sposób, dzięki. Na pewno czekam na kolejne materiały
Bardzo dobry materiał
Dzięki za materiał, oglądałem wszystkie twoje filmy - przydają się aby się rozwijać jako programista, a także do pracy (bo wiadomo - nie wszystkich tych nowinek można w projektach użyć).
Szkoda, że tak mało subów masz bo materiały są naprawdę na poziomie - moim zdaniem jesteś polskim odpowiednikiem Nicka Chapsas'a.
Stary dzięki za komentarz.
Ja jestem świadomy, że skoro mówię po polsku o programowaniu to patrząc na inne kanały programistyczne to 10.000 subów to będzie szklany sufit.
Generalnie film fajny
lajkacza daje. Supi materiał
Bardzo przyjemnie mi się oglądało! :)
Powodzenia jutro na konferencji :)
Dzięki za filmik!
Komentarz motywacyjny.
Mega film. Czekam na więcej 😁
Dzięki, za wideo i wytłumaczenie tego nie łatwego tematu. Ja ostatnio dostałem kilka rzeczy do zrobienia w projekcie wykorzystującym CQRS oraz MediatR, szczerze powiedziawszy ciężko mi się tam odnaleźć, nadmienie, że jest to integrator z jednym z systemów Comarchowych. Pytanie jak najlepiej wejść w taki projekt, od czego zacząć jego poznawanie? jak Ty wchodzisz w nieznane "środowisko"? Jest jakiś przewodnik, po dziczy?
Jest moc
Rewelacja
komentarz do statystyk
❤🔥
Świetny materiał, chociaż nie łatwy. Dlatego mam kilka pytań :)
- można gdzieś zobaczyć kod źródłowy przykładu by sobie lepiej to układać?
- będzie coś więcej o tym jak robić sam event storming ?
- no i nie za bardzo zrozumiałem jak zrobić by w pewnym etapie procesu, zrobić tak że wykonanie komendy zostanie wykonane dopiero po zajściu x zdarzeń. Np dokonujemy jakiejś akcji która wymaga potwierdzenia kogoś innego i nie wiemy kiedy to nastąpi?
czyzby shadow of the beast on the background?
Dzięki za to Czarku.
Masz dar do tłumaczenia trudnych koncepcji w ciekawy sposób. Potrafisz wejść w głowę odbiorcy.
Pewnie nad tym pracujesz, ale możesz podjąć wysiłek nad wymową po polsku (łykanie głosek) i angielsku (nieprawidłowa wymowa). Pewnie mogłoby to jeszcze bardziej podnieść jakość Twoich materiałów.
Cieszę się, że jest ktoś taki jak Ty. Dałem suba, bo oglądałem listę Twoich nagrań i prawie wszystkie są na mojej liście "To learn...".
Poprosimy o dogłębny filmik o Event Sourcingu for dummies :*
ua-cam.com/video/h60e8sXJyX8/v-deo.html
Jesteś pewien, że źle napisana aplikacja to taka, gdzie odczyt coś zmienia? - np. counter wyświetleń (patrz UA-cam).
Oczywiście, możemy powiedzieć, że odczyt nie zmienia nic w stanie aplikacji, jest to oddzielny proces. Natomiast odczyt jest jego wyzwalaczem i użytkownik nie robi oddzielnego "commanda" aby podbić licznik.
Odczyt też jest np. wykorzystywany przy profilowaniu, zbieranie danych na potrzeby dostarczania odpowiednich treści, a jest to wywoływane jedynie odczytem użytkownika.
W tej filozofii, jeśli odczyt danych z jakiegoś powodu coś jeszcze modyfikuje to nie jest to tak naprawdę odczyt.
Poruszyłeś też inną kwestię związaną z CQRS. Przykładowo Command nie powinien niczego zwracać (ja akurat nie trzymam się tej zasady zawsze). Co znaczy, że po modyfikacji, czyli zrobienia Command trzeba zrobić Query.
Stąd pojawiają się takie pytania,a po co to dzielić w ogóle, kiedy muszę wysłać dwa żądania do serwera.
Jednakże bez CQRS właściwie nie można moim zdaniem tworzyć oprogramowania gdzie są zdarzenia , a potem różne wzorce związane z mikroserwisami.
@@CezaryWalenciuk chyba brakuje tu definicji do jakiego poziomu schodzimy z CQRSem (front, api, serwisy, orm, db) i co oznacza "coś zwrócić" i "do kogo zwrócić" oraz "kto wywołuje proces".
Nie wiem czy dobrze rozumiem, sugerujesz, że w przypadku z licznikiem YT, po requesta(get - querry) przez użytkownika (aktora) i pobraniu treści w postaci wideo. Dalej użytkownik (aktor) - wykonuje ręcznie/automatycznie request (command) o podbicie licznika? czuję, że tu byłyby dziury gdyby użytkownik sterował/wywoływał proces zarządzania licznikiem(inkrementacją). Ale do sprawdzenia.
Trochę dziwi mnie generalizowanie, że "Command nie powinien niczego zwracać", Przy tworzeniu RESTowego api zawsze będziesz działał w komunikacji synchronicznej, mimo, że pod spodem procesy są obsługiwane asynchronicznie. I Command jak i Querry zawsze coś zwracają do klienta - response np. kod http (created/accepted ect.), można powiedzieć "nie zwracam na to uwagi" ale to dalej zwraca informację - czy to oznacza, że implementacja CQRS nie może opierać się na RESTowym API ponieważ respons wraca do klienta/aktora?
Oczywiście tu się jeszcze wkrada temat np. kolejkowania, podejścia fire and forget - ale to za chwilę.
Za głośno ta muzyka w tle
Dzięki :) Następnym razem będzie ciszej
takze ten paczka mediatR jest supaR