Tak miło się ogląda 😎, że aż naszły mnie dwie refleksje: 1. To teraz zróbcie to samo tylko z Event Sourcingiem 🤪 2. Przydałby się odcinek pt. "Jak rozmawiać z biznesem". U mnie w firmie niestety nie ma nawyku zrozumienia domeny, ani przez architekta, ani czasami przez sam biznes. I nawet jak programiści ogarniają DDD, to co z tego, skoro osoby decyzyjne (architekci, BAs, POs) nawet nie wiedzą o czym programiści mówią.😅 zróbcie, byle działało, a kontekstem to kto by się przejmował 🤦♂️
Dzięki! 1) Może kiedyś się pojawi z bardziej kompetentnym gościem niż my ;) 2) O samej komunikacji będzie wydzielona sekcja w kursie, choć zagaimy o to też w materiale na YT, który wpadnie najprawdopodobniej w przyszłym tygodniu :P
Moim zdaniem to w ogóle pomylenie porządków że to programiści ogarniają DDD a nie BA czy też analitycy systemowi - programiści to powinni mieć podane na tacy przez analityków.
Nie rozumiem dlaczego jest tyle tłumaczenia z grafu obiektów. Wg. mnie agregat jest szczególnym rodzajem grafu obiektów, w którym jakiś obiekt jest nadrzędny (root) i tylko przez niego uzyskujemy dostęp do reszty. Coś źle rozumiem, czy po prostu tłumaczycie to w skomplikowany sposób? ;)
ok. 12:00 A w ogóle to dlaczego zostało to zaprojektowane tak, że jest "zahardcodowana" stała w postaci kwartału? Czy gdybym zaprojektował jakiś mechanizm pozwalający na ustawienie limitu ilości X w jakimś czasie T dla produktu to było by to uznane za niepotrzebną pracę / został bym posądzony o robienie rzeczy o które biznes nie prosił? Jak to jest w firmach w których pracujecie?
45:00 W przypadku limitu zakupu produktu x na kwartał jest to niby niezmiennik, ale świat się nie zawali jeżeli ktoś w ciągu tych 5ms zrobi jednocześnie dwa zamówienia, i kupi 2 szt produktu. Wg. mnie dyskusja na temat czasu trwania zapisu zamówienia nie ma sensu, bo jej wynik i tak nie jest jednoznaczny (otrzymujemy większe lub mniejsze niezerowe prawdopodobieństwo). Moim zdaniem bardziej zasadna była by dyskusja (najlepiej z biznesem/inwestorem) jak bardzo krytyczna/twarda jest ta reguła. Teoretycznie można tą regułę obejść kupując drugi egzemplarz podając dane babci i poświęcanie kilku godzin z życia programisty żeby zagwarantować działanie reguły, którą i tak można obejść w prosty sposób. Określenie wagi problemu czy danej reguły biznesowej jest ważna. Tak czy inaczej, tego rodzaju wyzwania czasami trzeba na prawdę traktować bardzo poważnie i umieć je ogarniać (np. stosując jakieś locki). Wasz model i ta (mimo tego bardzo dobra) seria filmów o DDD, w ogóle nie obejmuje niektórych innych problemów, np. problemu podwójnego zakupu towaru, którego jest 1 szt towaru na stanie i dwie osoby kupują go jednocześnie, a taka sytuacja chyba zdarza się w dużych e-commerce. Tak czy inaczej na pewno należy rozmawiać z biznesem o tym jak "twarde" mają być reguły biznesowe. Nie jest to system bankowy, który po prostu musi za wszelką cenę gwantować uniemożliwiać przelanie np. ostatniej złótówki dwa razy, ale oczywiście ten materiał nie jest o systemach bankowych czy finansowych w których z resztą stosuje się chyba nieco inne architektury oraz narzędzia w których locki są powszechnie stosowane i wygodne w implementacji.
Czy trzecia reguła nie powinna być już jakoś sprawdzana na poziomie koszyka/checkout'u? Przedstawiona implementacja pozwala na dodanie 2 sztuk limitowanego produktu do koszyka, gdzie teoretycznie z góry wiadomo, że to nie przejdzie. Z punktu widzenia klienta przy tak oczywistym przypadku lepiej byłoby chyba od razu dostać informację zwrotną niż przechodzić przez cały proces checkout'u lub nawet dalej do płatności w przypadku gdzie 3cia reguła jest sprawdzana asynchronicznie.
Mówisz tylko o natychmiast dostepnej informacji - tej, która zawiera się w ramach koszyka. 🤔 Przypadku gdy dodasz jeden limitowany produkt do koszyka, który kupiłeś już w tym kwartale (zrealizowane zamowienie) w ramach koszyka nie "zamkniesz". 😅 Oczywiście można argumentować, że dla tak prostego przypadku nie ma co się bawić w takie podejście i jest to poniekąd prawda (trochę spróbujemy tego dotknac w jednym z kolejnych materialow) ale i ból materiałów na YT - zauważ że dochodziliśmy do tego case'u prawie 2h (a jest to naprawdę najkrótsza możliwa ścieżka jaka daliśmy radę nagrać). Pokazanie trudniejszego przypadku wymagałoby jeszcze szerszego zarysowania kontekstu, co by po prostu wszystkich zniechęciło. 😞 Jedyne co pozostaje mi polecić, to spróbować przełożyć te założenia na większy system i bardziej złożony proces, najlepiej taki, nad którym pracujemy na codzień. Wtedy pewnie benefity będą bardziej widoczne, ofc nie w każdym przypadku. 😉 /Michau
@@michawilczynski4992 Właśnie wiem, że przypadku z dodaniem jednego limitowanego produktu, który zakupiłem w danym kwartale w ramach koszyka sensownie nie zamknę. Stąd właśnie moje pytanie bo teoretycznie wariant, że ktoś doda 2 limitowane produkty w ramach jednego koszyka pewnie w praktyce wydarzy się częściej. Jest to dość ciekawy przypadek i zastanawiam się jak można by przemodelować agregaty żeby to sensownie obsłużyć. Z drugiej strony pewnie w przypadku realnej aplikacji sprawdzenie na poziomie dodawania do koszyka zrobiłbym po stronie frontendu czym uzyskałbym ten lepszy user experience
"Przedstawiona implementacja pozwala na dodanie 2 sztuk limitowanego produktu do koszyka, gdzie teoretycznie z góry wiadomo, że to nie przejdzie" Akurat przedstawiona implementacja sprawi, że jeśli do jednego zamówienia dodasz 2 (lub więcej) sztuk jednego produktu (choćby limitowanego) to to przejdzie. Nie tylko przez weryfikację na poziomie koszyka, ale również na poziomie agregatu. Jedynym warunkiem jest, by te kolejne sztuki dodać jako kolejne pozycje w koszyku, a nie jako wiele sztuk. Czyli dodajesz 10 razy po 1 sztuce PSP i tyle.
Podbijam do pytania. O ile komuś kto juz kodzi to w miarę łatwo to wszystko zrozumieć i ogólnie widzę w tym dużo b.fajnych treści, to trochę współczuję początkującym :D
Dla mnie to całe DDD to komplikowanie życia, jechanie po performance i wynikająca z tego mniejsza satysfakcja klienta. Filozofowanie nad problemami z grupy not rocket science. Ale może kiedyś zmienię zdanie 😊
Hehe 'jak krytykujesz to nie rozumiesz' :) mi generalnie DDD nie przeszkadza, ale osobiscie uwazam ze pare rzeczy w nim jest durnowate, i nie warto go na slepo stosowac. Plus z czegos trzeba te magisterki pisac.
Prosiłbym jak najwięcej o DDD strategicznym. Przykładowe sesje event stormingu np albo innych metodyk
Tak miło się ogląda 😎, że aż naszły mnie dwie refleksje:
1. To teraz zróbcie to samo tylko z Event Sourcingiem 🤪
2. Przydałby się odcinek pt. "Jak rozmawiać z biznesem". U mnie w firmie niestety nie ma nawyku zrozumienia domeny, ani przez architekta, ani czasami przez sam biznes. I nawet jak programiści ogarniają DDD, to co z tego, skoro osoby decyzyjne (architekci, BAs, POs) nawet nie wiedzą o czym programiści mówią.😅 zróbcie, byle działało, a kontekstem to kto by się przejmował 🤦♂️
Dzięki!
1) Może kiedyś się pojawi z bardziej kompetentnym gościem niż my ;)
2) O samej komunikacji będzie wydzielona sekcja w kursie, choć zagaimy o to też w materiale na YT, który wpadnie najprawdopodobniej w przyszłym tygodniu :P
korpo tak mają :) cza z tym żyć
Moim zdaniem to w ogóle pomylenie porządków że to programiści ogarniają DDD a nie BA czy też analitycy systemowi - programiści to powinni mieć podane na tacy przez analityków.
Nie rozumiem dlaczego jest tyle tłumaczenia z grafu obiektów. Wg. mnie agregat jest szczególnym rodzajem grafu obiektów, w którym jakiś obiekt jest nadrzędny (root) i tylko przez niego uzyskujemy dostęp do reszty. Coś źle rozumiem, czy po prostu tłumaczycie to w skomplikowany sposób? ;)
ok. 12:00 A w ogóle to dlaczego zostało to zaprojektowane tak, że jest "zahardcodowana" stała w postaci kwartału?
Czy gdybym zaprojektował jakiś mechanizm pozwalający na ustawienie limitu ilości X w jakimś czasie T dla produktu to było by to uznane za niepotrzebną pracę / został bym posądzony o robienie rzeczy o które biznes nie prosił? Jak to jest w firmach w których pracujecie?
45:00 W przypadku limitu zakupu produktu x na kwartał jest to niby niezmiennik, ale świat się nie zawali jeżeli ktoś w ciągu tych 5ms zrobi jednocześnie dwa zamówienia, i kupi 2 szt produktu. Wg. mnie dyskusja na temat czasu trwania zapisu zamówienia nie ma sensu, bo jej wynik i tak nie jest jednoznaczny (otrzymujemy większe lub mniejsze niezerowe prawdopodobieństwo). Moim zdaniem bardziej zasadna była by dyskusja (najlepiej z biznesem/inwestorem) jak bardzo krytyczna/twarda jest ta reguła. Teoretycznie można tą regułę obejść kupując drugi egzemplarz podając dane babci i poświęcanie kilku godzin z życia programisty żeby zagwarantować działanie reguły, którą i tak można obejść w prosty sposób. Określenie wagi problemu czy danej reguły biznesowej jest ważna. Tak czy inaczej, tego rodzaju wyzwania czasami trzeba na prawdę traktować bardzo poważnie i umieć je ogarniać (np. stosując jakieś locki). Wasz model i ta (mimo tego bardzo dobra) seria filmów o DDD, w ogóle nie obejmuje niektórych innych problemów, np. problemu podwójnego zakupu towaru, którego jest 1 szt towaru na stanie i dwie osoby kupują go jednocześnie, a taka sytuacja chyba zdarza się w dużych e-commerce. Tak czy inaczej na pewno należy rozmawiać z biznesem o tym jak "twarde" mają być reguły biznesowe. Nie jest to system bankowy, który po prostu musi za wszelką cenę gwantować uniemożliwiać przelanie np. ostatniej złótówki dwa razy, ale oczywiście ten materiał nie jest o systemach bankowych czy finansowych w których z resztą stosuje się chyba nieco inne architektury oraz narzędzia w których locki są powszechnie stosowane i wygodne w implementacji.
Czy trzecia reguła nie powinna być już jakoś sprawdzana na poziomie koszyka/checkout'u? Przedstawiona implementacja pozwala na dodanie 2 sztuk limitowanego produktu do koszyka, gdzie teoretycznie z góry wiadomo, że to nie przejdzie. Z punktu widzenia klienta przy tak oczywistym przypadku lepiej byłoby chyba od razu dostać informację zwrotną niż przechodzić przez cały proces checkout'u lub nawet dalej do płatności w przypadku gdzie 3cia reguła jest sprawdzana asynchronicznie.
Mówisz tylko o natychmiast dostepnej informacji - tej, która zawiera się w ramach koszyka. 🤔
Przypadku gdy dodasz jeden limitowany produkt do koszyka, który kupiłeś już w tym kwartale (zrealizowane zamowienie) w ramach koszyka nie "zamkniesz". 😅
Oczywiście można argumentować, że dla tak prostego przypadku nie ma co się bawić w takie podejście i jest to poniekąd prawda (trochę spróbujemy tego dotknac w jednym z kolejnych materialow) ale i ból materiałów na YT - zauważ że dochodziliśmy do tego case'u prawie 2h (a jest to naprawdę najkrótsza możliwa ścieżka jaka daliśmy radę nagrać).
Pokazanie trudniejszego przypadku wymagałoby jeszcze szerszego zarysowania kontekstu, co by po prostu wszystkich zniechęciło. 😞
Jedyne co pozostaje mi polecić, to spróbować przełożyć te założenia na większy system i bardziej złożony proces, najlepiej taki, nad którym pracujemy na codzień. Wtedy pewnie benefity będą bardziej widoczne, ofc nie w każdym przypadku. 😉
/Michau
@@michawilczynski4992 Właśnie wiem, że przypadku z dodaniem jednego limitowanego produktu, który zakupiłem w danym kwartale w ramach koszyka sensownie nie zamknę. Stąd właśnie moje pytanie bo teoretycznie wariant, że ktoś doda 2 limitowane produkty w ramach jednego koszyka pewnie w praktyce wydarzy się częściej. Jest to dość ciekawy przypadek i zastanawiam się jak można by przemodelować agregaty żeby to sensownie obsłużyć. Z drugiej strony pewnie w przypadku realnej aplikacji sprawdzenie na poziomie dodawania do koszyka zrobiłbym po stronie frontendu czym uzyskałbym ten lepszy user experience
"Przedstawiona implementacja pozwala na dodanie 2 sztuk limitowanego produktu do koszyka, gdzie teoretycznie z góry wiadomo, że to nie przejdzie" Akurat przedstawiona implementacja sprawi, że jeśli do jednego zamówienia dodasz 2 (lub więcej) sztuk jednego produktu (choćby limitowanego) to to przejdzie. Nie tylko przez weryfikację na poziomie koszyka, ale również na poziomie agregatu. Jedynym warunkiem jest, by te kolejne sztuki dodać jako kolejne pozycje w koszyku, a nie jako wiele sztuk. Czyli dodajesz 10 razy po 1 sztuce PSP i tyle.
W jakim języku jest kurs? Wydaję mi się, ze po polsku, ale wolę dopytać 😀
PL 😉
Podbijam do pytania. O ile komuś kto juz kodzi to w miarę łatwo to wszystko zrozumieć i ogólnie widzę w tym dużo b.fajnych treści, to trochę współczuję początkującym :D
@DevMentors
Bedzie pre-sale w bundle?
Dopiero gdy kurs będzie w regularnej sprzedaży
@@DevMentorsPL Wiesz może jaka będzie cena w pakiecie wszystko bez `SOLIDne WebApi` ? :D
Co to za skin do Ridera? :)
Jest wrzucony na naszego discorda ;)
Dla mnie to całe DDD to komplikowanie życia, jechanie po performance i wynikająca z tego mniejsza satysfakcja klienta. Filozofowanie nad problemami z grupy not rocket science. Ale może kiedyś zmienię zdanie 😊
To znaczy, że nie rozumiesz istoty tego podejścia 😉
Hehe 'jak krytykujesz to nie rozumiesz' :) mi generalnie DDD nie przeszkadza, ale osobiscie uwazam ze pare rzeczy w nim jest durnowate, i nie warto go na slepo stosowac. Plus z czegos trzeba te magisterki pisac.
rozumiem, ze w 2024 promocji nie ma?:)
W najblizszym czasie powinna byc szansa na kolejna promke wraz z mozliwoscia przetestowania nowej wiedzy w boju. 😉
Halo halo nawet bardziej doświadczone osoby nie maja ochoty czytać kilku tysięczników XD
Pierwszy? 🙂
Przed 301 #pdk :D