Masz niesamowity dar tłumaczenia i wyjaśniania tych zagadnień - te obrazki, grafiki, wykresy, to robi super robote i pozwala lepiej zrozumieć i zapamiętać poruszanne zagadnienia. Super, że jest co raz więcej subskrypcji! Super kanał!
Dzięki za komentarz! Miło się takie rzeczy czyta! Jeśli chodzi o plany, to chciałbym wydać szkolenie na temat architektury oprogramowania i organizacji kodu, ale w sposób pragmatyczny. Obecnie prowadzę kilka szkoleń w formie stacjonarnej, zbieram feedback i mam plan, że gdy przez te szkolenia przejdzie 200-300 osób, zgrupuję to wszystko, podsumuję cały feedback, dostosuję materiał i wypuszczę w formie online. Szkolenia prowadzę dopiero od tego roku, a na chwilę obecną przerobiło je już około 130 osób, więc myślę, że w przyszłym roku uda mi się wydać takie kompleksowe szkolenie, trzymając się swojej formy przekazywania wiedzy. Jeśli plan się ziści, na pewno dam znać na TH-cam, ale mam też newsletter na blogu javasenior.pl/, gdzie również będę wysyłał wiadomości :D Jeśli masz jakieś sugestie (lub ktoś inny, kto to czyta), co warto poruszyć w szkoleniu albo co poprawić w filmikach, chętnie przyjmę każdy feedback. Szkolenie planuje w podobnej formie co filmiki, ale bardziej rozbudowane i z większą liczbą tematów i przykładów. Więc chętnie biorę każdą sugestię można napisać tutaj, albo skontaktować się na LinkedIn. Każda rada jest cenna! PS. @szejmys1899 Dzięki za to pytanie!
Ciekawy przykład z tym agregatem i metodami use i deactivate, natomiast pojawiły się u mnie 3 pytania :D 1. Wspomniałeś o metodach use i deactivate, że należą do wspólnego agregatu ponieważ wzajemnie oraz samoistnie się blokują, i dopiero po tym dobierasz pola. Jak bez implikowania, że istnieje np. pole status można stwierdzić, że dane komendy będą się wzajemnie blokować? th-cam.com/video/kUvugLIsivg/w-d-xo.html 2. Metoda zmiany deskrypcji, a raczej to, że ona tylko modyfikuje tylko przez nią używane pola i nie zasługuje na bycie w agregacie oraz wyniesienie jej do np encji CouponDetail jest ok. Natomiast gdyby teraz pojawiło się wymaganie, że opis można zmienić tylko na aktywnym kuponie, to wrzucił byś ją z powrotem do agregatu kuponu? Czy raczej, jeżeli biznes pozwala na eventual consistency paru sekund, uczyniłbyś z CouponDetail osobny agregat z referencją do agregatu Coupon i kopią statusu? Idąc zasadą, żeby trzymać agregaty małymi 3. Podałeś przykład, że jeżeli masz kupon i metodę use, to implikuje to, że metoda będzie samoblokująca (bo ma też stan), natomiast potem dodałeś, że jeżeli wywołanie tej metody w tym samym czasie, ale w innym wątku i z niepoprawnym customerId nie spowoduje, że metoda, a raczej wywołanie będzie blokujące th-cam.com/video/kUvugLIsivg/w-d-xo.html czy tutaj mógłbyś rozwinąć jaki był cel pokazania tego? Co z tego wynika? Czy chciałeś tutaj podkreślić dwa typy warunków, jeden oparty na niezmienniku który nie daje gwarancji operacji dołączenia do agregatu, i drugim typie, opartym na zmienniku - statusie, który ją do tego uprawnia?
Dzięki za komentarz! Super pytanie, to trzecie pytanie uświadomiło mi, że dodałem coś do filmu i nie wyjaśniłem tego dokładnie. Dzięki za zwrócenie na to uwagi, następnym razem będę musiał przyłożyć do tego większą wagę! 1. Komendy będą miały za zadanie zmienić jakieś pole pod pewnymi warunkami. To, co ma się zmienić i pod jakimi warunkami, dowiemy się od biznesu. W tym przypadku to nie musi być to pole 'status', ale równie dobrze może być boolean 'isActive'. To, że użyłem 'status', wynika z znajomości domeny, bo kupon prawdopodobnie będzie miał więcej stanów, takich jak 'EXPIRED' czy 'PENDING'. Ale gdy biznes powiedział, że kupon można jeszcze użyć do 5 godzin po jego deaktywacji, moglibyśmy nie używać 'status', a zamiast tego dwa pola: 'dateOfUse' i 'dateOfDeactive', które byłyby używane w warunkach. Podsumowując, tworzymy agregat, gdy już mamy pojęcie o biznesie i wiemy mniej więcej, co opisuje dany zasób, więc tu jest kwestia, które z tych pól potrzebujemy włączyć do agregatu (czasami mogą powstać pola, o których biznes bezpośrednio nie mówi, tylko trzeba je wydedukować). 2. Żeby odpowiedzieć na to pytanie, trzeba by zadać kilka pytań biznesowi, np.: Co się złego stanie, jeśli zmieni się opis na użytym kuponie? Jeśli możemy zaakceptować eventual consistency i potrzebujemy skalowalności, to warto w to iść. Tutaj warto również podkreślić, że jeśli istnieje wiele operacji, które można wykonać tylko w danym stanie agregatu, można rozważyć tworzenie nowego agregatu z istniejącego. Na przykład, jeśli agregat reprezentujący ofertę zostaje zaakceptowany, staje się agregatem zamówienia. Ale to temat, który nie był poruszany w tym filmiku, choć warto byłoby o nim wspomnieć. 😀 3. Aj, tu mnie masz! Początkowo chciałem bardziej rozwinąć ten przykład, ale stwierdziłem, że nie chcę zbytnio komplikować sprawy plus akurat dla kuponu trzeba by szukać dziwnych wymagań, żeby miało to większy sens. No i został ten przykład z 'customerId', który w tym filmiku nic nie wnosi😅 Ale opisze to na jakieś domenie która lepiej to obrazuje. Np. mamy stolik w restauracji i ktoś go rezeruję od 16-17 i ktoś inny od 19-20. Czyli rezerwacja na ten sam stolik w tym samym momencie, ta sama komenda, nie powinny się blokować, bo komenda jest wołana z warunkami które nie blokujące się. W takich sytuacjach w bazie danych tworzy się osobny wpis dla każdego slotu czasowego, np. dla każdej godziny. Dzięki temu każdy wpis ma swojego optimistic lock i wywołanie tej samej komendy z innymi warunkami się nie blokuje, bo korzysta z innego wpisu na bazce. Ale to są trudniejsze przykłady i nie chciałem ich wrzucać do filmiku o idei agregatu, więc to 'customerId' trochę niepotrzebnie tam się znalazło :D
@@javaseniorpl Dzięki za odpowiedzi, dużo rozjaśniły :) Generalnie super seria, chyba najlepsza jeżeli chodzi takie upakowanie wiedzy z DDD. Liczę na część strategiczną :D edit: ad3, tutaj pewnie można by było polemizować, co by było agregatem Czy stolik, który ma na sobie rezerwacje i jest atomowy, ale kosztem wydajności, czy rezerwacja, która ma na sobie id agregatu/encji stolika, ale sama w sobie nie może sprawdzić, czy inne "agregaty" rezerwacji na nią nie nachodzą, więc musi oddelegować to "wyżej". Wydaje mi się, że po części to problem klasy DDD trillema
Najlepsze wytłumaczenie agregatu jakie kiedykolwiek widzialem. Dobra robota!
Kolejny świetny materiał! Dzięki!
Masz niesamowity dar tłumaczenia i wyjaśniania tych zagadnień - te obrazki, grafiki, wykresy, to robi super robote i pozwala lepiej zrozumieć i zapamiętać poruszanne zagadnienia. Super, że jest co raz więcej subskrypcji! Super kanał!
Dzięki wielkie za feedback, po takim komentarzu od razu +5 do chęci tworzenia kolejnych filmików!
kurcze dobre te filmy, przedewszystkim dobrze ze sa przykłady
Dzięki wielkie! Staram się, mam nadzieję, że kolejne będą jeszcze lepsze :D
Kolejny materiał TOP. Czy można Cię jakoś wesprzeć? Czy myślałeś o dłuższych seriach kursów? Bo wiedza wpada do głowy jak szalona :D
Dzięki za komentarz! Miło się takie rzeczy czyta!
Jeśli chodzi o plany, to chciałbym wydać szkolenie na temat architektury oprogramowania i organizacji kodu, ale w sposób pragmatyczny. Obecnie prowadzę kilka szkoleń w formie stacjonarnej, zbieram feedback i mam plan, że gdy przez te szkolenia przejdzie 200-300 osób, zgrupuję to wszystko, podsumuję cały feedback, dostosuję materiał i wypuszczę w formie online.
Szkolenia prowadzę dopiero od tego roku, a na chwilę obecną przerobiło je już około 130 osób, więc myślę, że w przyszłym roku uda mi się wydać takie kompleksowe szkolenie, trzymając się swojej formy przekazywania wiedzy. Jeśli plan się ziści, na pewno dam znać na TH-cam, ale mam też newsletter na blogu javasenior.pl/, gdzie również będę wysyłał wiadomości :D
Jeśli masz jakieś sugestie (lub ktoś inny, kto to czyta), co warto poruszyć w szkoleniu albo co poprawić w filmikach, chętnie przyjmę każdy feedback. Szkolenie planuje w podobnej formie co filmiki, ale bardziej rozbudowane i z większą liczbą tematów i przykładów. Więc chętnie biorę każdą sugestię można napisać tutaj, albo skontaktować się na LinkedIn. Każda rada jest cenna!
PS. @szejmys1899 Dzięki za to pytanie!
Świetnie wytłumaczone :)
Dzięki wielkie!
Elegancko jest szefie, elegancko.
Dzięki!
Ciekawy przykład z tym agregatem i metodami use i deactivate, natomiast pojawiły się u mnie 3 pytania :D
1. Wspomniałeś o metodach use i deactivate, że należą do wspólnego agregatu ponieważ wzajemnie oraz samoistnie się blokują, i dopiero po tym dobierasz pola. Jak bez implikowania, że istnieje np. pole status można stwierdzić, że dane komendy będą się wzajemnie blokować? th-cam.com/video/kUvugLIsivg/w-d-xo.html
2. Metoda zmiany deskrypcji, a raczej to, że ona tylko modyfikuje tylko przez nią używane pola i nie zasługuje na bycie w agregacie oraz wyniesienie jej do np encji CouponDetail jest ok. Natomiast gdyby teraz pojawiło się wymaganie, że opis można zmienić tylko na aktywnym kuponie, to wrzucił byś ją z powrotem do agregatu kuponu? Czy raczej, jeżeli biznes pozwala na eventual consistency paru sekund, uczyniłbyś z CouponDetail osobny agregat z referencją do agregatu Coupon i kopią statusu? Idąc zasadą, żeby trzymać agregaty małymi
3. Podałeś przykład, że jeżeli masz kupon i metodę use, to implikuje to, że metoda będzie samoblokująca (bo ma też stan), natomiast potem dodałeś, że jeżeli wywołanie tej metody w tym samym czasie, ale w innym wątku i z niepoprawnym customerId nie spowoduje, że metoda, a raczej wywołanie będzie blokujące th-cam.com/video/kUvugLIsivg/w-d-xo.html czy tutaj mógłbyś rozwinąć jaki był cel pokazania tego? Co z tego wynika? Czy chciałeś tutaj podkreślić dwa typy warunków, jeden oparty na niezmienniku który nie daje gwarancji operacji dołączenia do agregatu, i drugim typie, opartym na zmienniku - statusie, który ją do tego uprawnia?
Dzięki za komentarz! Super pytanie, to trzecie pytanie uświadomiło mi, że dodałem coś do filmu i nie wyjaśniłem tego dokładnie. Dzięki za zwrócenie na to uwagi, następnym razem będę musiał przyłożyć do tego większą wagę!
1. Komendy będą miały za zadanie zmienić jakieś pole pod pewnymi warunkami. To, co ma się zmienić i pod jakimi warunkami, dowiemy się od biznesu. W tym przypadku to nie musi być to pole 'status', ale równie dobrze może być boolean 'isActive'. To, że użyłem 'status', wynika z znajomości domeny, bo kupon prawdopodobnie będzie miał więcej stanów, takich jak 'EXPIRED' czy 'PENDING'. Ale gdy biznes powiedział, że kupon można jeszcze użyć do 5 godzin po jego deaktywacji, moglibyśmy nie używać 'status', a zamiast tego dwa pola: 'dateOfUse' i 'dateOfDeactive', które byłyby używane w warunkach. Podsumowując, tworzymy agregat, gdy już mamy pojęcie o biznesie i wiemy mniej więcej, co opisuje dany zasób, więc tu jest kwestia, które z tych pól potrzebujemy włączyć do agregatu (czasami mogą powstać pola, o których biznes bezpośrednio nie mówi, tylko trzeba je wydedukować).
2. Żeby odpowiedzieć na to pytanie, trzeba by zadać kilka pytań biznesowi, np.: Co się złego stanie, jeśli zmieni się opis na użytym kuponie? Jeśli możemy zaakceptować eventual consistency i potrzebujemy skalowalności, to warto w to iść.
Tutaj warto również podkreślić, że jeśli istnieje wiele operacji, które można wykonać tylko w danym stanie agregatu, można rozważyć tworzenie nowego agregatu z istniejącego. Na przykład, jeśli agregat reprezentujący ofertę zostaje zaakceptowany, staje się agregatem zamówienia. Ale to temat, który nie był poruszany w tym filmiku, choć warto byłoby o nim wspomnieć. 😀
3. Aj, tu mnie masz! Początkowo chciałem bardziej rozwinąć ten przykład, ale stwierdziłem, że nie chcę zbytnio komplikować sprawy plus akurat dla kuponu trzeba by szukać dziwnych wymagań, żeby miało to większy sens. No i został ten przykład z 'customerId', który w tym filmiku nic nie wnosi😅
Ale opisze to na jakieś domenie która lepiej to obrazuje. Np. mamy stolik w restauracji i ktoś go rezeruję od 16-17 i ktoś inny od 19-20. Czyli rezerwacja na ten sam stolik w tym samym momencie, ta sama komenda, nie powinny się blokować, bo komenda jest wołana z warunkami które nie blokujące się.
W takich sytuacjach w bazie danych tworzy się osobny wpis dla każdego slotu czasowego, np. dla każdej godziny. Dzięki temu każdy wpis ma swojego optimistic lock i wywołanie tej samej komendy z innymi warunkami się nie blokuje, bo korzysta z innego wpisu na bazce. Ale to są trudniejsze przykłady i nie chciałem ich wrzucać do filmiku o idei agregatu, więc to 'customerId' trochę niepotrzebnie tam się znalazło :D
@@javaseniorpl Dzięki za odpowiedzi, dużo rozjaśniły :) Generalnie super seria, chyba najlepsza jeżeli chodzi takie upakowanie wiedzy z DDD. Liczę na część strategiczną :D
edit: ad3, tutaj pewnie można by było polemizować, co by było agregatem
Czy stolik, który ma na sobie rezerwacje i jest atomowy, ale kosztem wydajności, czy rezerwacja, która ma na sobie id agregatu/encji stolika, ale sama w sobie nie może sprawdzić, czy inne "agregaty" rezerwacji na nią nie nachodzą, więc musi oddelegować to "wyżej". Wydaje mi się, że po części to problem klasy DDD trillema