Bardzo dużo praktycznej wiedzy, na której można budować swoje fundamenty w nowym spojrzeniu na projekt. Forma przekazu jest bardzo czytelna, a w głowie zostaje samoistnie masa informacji, dzięki takim konkretnym, życiowym przykładom. Dzięki za możliwość poszerzania kompetencji, a przy okazji czerpania z tego wielkiej frajdy.
Podoba mi się dźwięk jak pokazujecie coś na ekranie, np schemat produktu czy shota z karonu. Mogę sobie puścić video, zamknąć oczy i dać im odpocząć, a jak coś się dzieje to zerknąć. Sam materiał super, czasem mam wrażenie, że Michał nie daje dokończyć myśli Darkowi 😅
Dzięki😃 Co do przerywania to Michał musiał to robić, bo inaczylej bym mu nie dał dojść do słowa (patrz vlog z biuru) 😅 Potrzebujemy chwili, żeby się dotrzeć ze swoim stylem 😉 /D
Dzięki - bardzo czytelnie wytłumaczyliście. Dla kompletności można by dodać jeszcze warstwę aplikacyjną i pokazać w niej persystencje encji, które wytworzyliście. Może w następnym odcinku?
Dzieki! Z persistence sprobujemy moze w jeszcze kolejnym materiale gdzie bedziemy musieli wyjsc poza model do app layer zeby pokazac konsekwencje roznych decyzji. 😉 - Michau
Świetna robota i super materiał. Mam tylko uwagę, czy jednak nie lepiej by było trzymać jakąkolwiek informacje w OrderLine, jaki dokładnie produkt został zamówiony. Np. po to, żeby móc zrobić to co w x-komie, czyli przejść do aktualnej strony z aktualną ceną i wyglądem produktu, który kupiliśmy kiedyś tam. Wydaje mi się, że w obecnym modelu straciliśmy tę informację w Order.
Pytanie spoza ddd (a może nie) ale do waszego kodu, czy rzucanie wyjątków jako zgłoszenie nieprawidłowości walidacji np productCount < 1 throw JakisTamException to dobra praktyka? Raczej zawsze słyszałem, że rzucanie wyjątków jest dość ciężką operacja i nie nalezy ich rzucac jako część logiki biznesowej aplikacji. Dodatkowo jeżeli chcielibyśmy zebrać kilka problemów walidacyjnych jakie wystąpiły w formularzu, przy tym podejsciu możemy wyświetlić tylko jeden exception
Dzięki za dobry materiał 💪 Ale nurtuje mnie jedna rzecz.. W klasie 'Cart' w metodzie 'AddProduct' sprawdzacie czy 'Quantity' danego 'CarrProduct' nie przekracza limitu dwóch sztuk. Czy ta logika nie powinna należeć do klasy 'CartProduct'? Bo to chyba delikatny 'code smell', jeśli dobrze kojarzę PS: Chyba jest błąd logiczny, bo przy dwóch sztukach można dodać kolejną. A chcieliście ograniczyć do max 2 😀
Pytania: W Cart mamy CustomerID, czy zawsze wiemy jaki użytkownik wkłada produkty do koszyka? Bardzo często konto lub zapytanie o logowanie mamy dopiero na etapie zamówienia. Jak zrobić w takim razie transformację z anonimowej sesji do zalogowanego usera? Czy w Cart trzymamy wtedy ID sesji (jeśli to apikacja webowa) a w zamówieniu CustomerID to już będzie utworzone lub zalogowane konto? Czy może w Order będzie trzymane sessionID oraz customerID? Jak to ograć w CartCheckout wtedy?
czy planujecie wersje angielską kursu albo polecacie coś po angielsku? Po przerobieniu waszego chciał bym pokazać coś równie dobrego reszcie zespołu a on niestety anglojęzyczny
Poczułem się mądry, bo skodziłbym ten model w podobny sposób ;) Jednak problem jaki mam, to kiedy warto inwestować czas w lepszy model, jego odkrywanie i projektowanie (?), bo ja uważam, że zawsze, jednak PO z którymi zwykle mam do czynienia nie podzielają mojego entuzjazmu... Sprawa jest prosta z takim ecommerce, gorzej z projektami "w miarę nowymi", gdzie byty domenowe nie mapują się łatwo do archetypów, nie ma ekspertów, nie ma jednej wizji produktu, a PO twierdzi że nie ma sensu inwestować w zgrabny model póki użytkownicy nie zwalidują nam obecnej wersji produktu, bo jeszcze wszystko może się zmienić, nawet (a może zwłaszcza?) względem czegoś co zapowiada się na core :| Balans? Będzie coś o tym w kursie? Pewnie kupię i tak, bo robicie zajebistą robotę.
Myślę że w takiej sytuacji najlepszą rzeczą jaką można zrobić, to zdobyć jak najwięcej know-how z otoczenia biznesowego (kto jest/będzie naszym klientem, jaki problem rozwiązujemy, czym chcemy się wyróżniać etc.). Następnie przygotował bym model good enough na bazie naszej wiedzy i skupiłbym się przede wszystkim na jego gotowości na zmiany (ewolucję lub rewolucję, zaleznie od realiów tego biznesu). Można nawet pójść krok dalej i po tym modelu "good enough" zrobić PoC jakiegoś oczekiwanego kierunku rozwoju (rynek oczekuje X, rynek oczekuje Y etc). Pamietajmy, że model odzwierciedla nasza obecna wiedze - a ta jak już wiesz jest niekompletna na poziomie organizacji. Jak będzie wiadomo więcej to i model może dalej ewoluować. 😉 /Michau
Mam 1 problem z implementacją tego Cart'a mianowicie co jeśli użytkownik wyjdzie z widoku i wróci do niego za kilka minut, utworzy się nowy CheckoutCart, a poprzedni będzie stale i trzeba go będzie za każdym razem cron'em usuwać? Zakładam że musi wystąpić jakiś zapis, żeby klient po odświeżeniu strony(lub zmiany urządzenia) nie musiał za każdym razem wklepywać swoich danych
Fair point - przyklad jest oczywiście nieco okrojony by dalo się go w skończonym czasie pokazac i ogarnac (troche taki model, gdzie kontekstem problemu jest edukacja) 😉
Zabieram się za oglądanie, quality shit jak zwykle to można w ciemno napisać. Nurtuje mnie jednak jedna rzecz, skąd nagle ta moda na DDD? Przecież to jest podjeście, które istnieje już wiele lat. Teraz nagle cały yt (nie jest to zarzut w wasza strona, sam wsiadłem w ten hype-train a wiem, że z waszych materiałów dużo wyciągne) jest zalany DDD, tak samo w ofertach pracy coraz częściej wymagają tego podejścia. Wcześniej tak nie było.
Mysle że nałożyło się parę rzeczy: rośnie maturity branży i zaczynamy wszyscy rozumieć, że yet another framework nie zmienia tak znacząco niczego jeśli chodzi o sam biznes, dla którego budujemy rozwiazanie. Poza tym w erze GPT-3 i GPT-4 (czy ogólnie LLM) próg wejścia do "technicznego" kodzenia maleje. I z tego miejsca są (imho) dwie drogi: stać się częścią zespołu produktowego i samego biznesu lub specjalizować się w bardzo niszowych tematach wymagających bardzo dużej wiedzy technicznej. Oczywiście tak jak piszesz, DDD nie jest wcale nowe. Jego strategiczną część przynajmniej częściowo można podsumować słowami "najpierw myśl, potem rób". A jego taktyczna część to tak naprawdę "OOP done right". 😉 /Michau
Hmm, Order po zlozeniu moze byc zmodyfikowany , ale przez pracownika ;-) Bo jezeli zamowie 2x ten sam produkt, ale w magazynie sie okaze, ze jest tylko 1 to nie ma sensu anulowac calego zamowienia !
Pewnie, mówiliśmy chyba nawet o tym w materiale, ze ten case pominęliśmy. 😉 Żeby złapać całą domenę potrzeba paru godzin i szerszego kontekstu. W sumie zmiane mozna tu ograć zachowując continuity, tzn. tworzyć zamówienie z zamówienia (niektóre sklepy tak robią, wystawiają nowe zamowienie i stare anuluja). 🤔 Inna sprawa ze brak w magazynie fizycznej "sztuki" bedzie do ogrania pewnie w zupelnie innym miejscu (Shipping?), komunikacja z klientem tez w innym miejscu, a taka przebudowa zamowienia (lub ponowne utworzenie) bedzie juz troche wynikiem. /Michau
W końcu kanał na poziomie "nie dla początkujących" na krajowym youtubie :) Brawooo :) Robicie super robotę Panowie. Dzięki!
Bardzo dużo praktycznej wiedzy, na której można budować swoje fundamenty w nowym spojrzeniu na projekt.
Forma przekazu jest bardzo czytelna, a w głowie zostaje samoistnie masa informacji, dzięki takim konkretnym, życiowym przykładom.
Dzięki za możliwość poszerzania kompetencji, a przy okazji czerpania z tego wielkiej frajdy.
Podoba mi się dźwięk jak pokazujecie coś na ekranie, np schemat produktu czy shota z karonu. Mogę sobie puścić video, zamknąć oczy i dać im odpocząć, a jak coś się dzieje to zerknąć. Sam materiał super, czasem mam wrażenie, że Michał nie daje dokończyć myśli Darkowi 😅
Dzięki😃 Co do przerywania to Michał musiał to robić, bo inaczylej bym mu nie dał dojść do słowa (patrz vlog z biuru) 😅 Potrzebujemy chwili, żeby się dotrzeć ze swoim stylem 😉
/D
To jest kanał jakiego szukałem blisko rok
Miło czytać😄 Dzięki!
Świetna robota Panowie, nie przestawajcie :)
Dzięki - bardzo czytelnie wytłumaczyliście. Dla kompletności można by dodać jeszcze warstwę aplikacyjną i pokazać w niej persystencje encji, które wytworzyliście. Może w następnym odcinku?
Dzieki!
Z persistence sprobujemy moze w jeszcze kolejnym materiale gdzie bedziemy musieli wyjsc poza model do app layer zeby pokazac konsekwencje roznych decyzji. 😉
- Michau
Świetna robota i super materiał. Mam tylko uwagę, czy jednak nie lepiej by było trzymać jakąkolwiek informacje w OrderLine, jaki dokładnie produkt został zamówiony. Np. po to, żeby móc zrobić to co w x-komie, czyli przejść do aktualnej strony z aktualną ceną i wyglądem produktu, który kupiliśmy kiedyś tam. Wydaje mi się, że w obecnym modelu straciliśmy tę informację w Order.
Super materiał, thx ;)
Pytanie spoza ddd (a może nie) ale do waszego kodu, czy rzucanie wyjątków jako zgłoszenie nieprawidłowości walidacji np productCount < 1 throw JakisTamException to dobra praktyka? Raczej zawsze słyszałem, że rzucanie wyjątków jest dość ciężką operacja i nie nalezy ich rzucac jako część logiki biznesowej aplikacji. Dodatkowo jeżeli chcielibyśmy zebrać kilka problemów walidacyjnych jakie wystąpiły w formularzu, przy tym podejsciu możemy wyświetlić tylko jeden exception
super materiał, oby więcej panowie :)
Dzięki za dobry materiał 💪
Ale nurtuje mnie jedna rzecz.. W klasie 'Cart' w metodzie 'AddProduct' sprawdzacie czy 'Quantity' danego 'CarrProduct' nie przekracza limitu dwóch sztuk. Czy ta logika nie powinna należeć do klasy 'CartProduct'? Bo to chyba delikatny 'code smell', jeśli dobrze kojarzę
PS: Chyba jest błąd logiczny, bo przy dwóch sztukach można dodać kolejną. A chcieliście ograniczyć do max 2 😀
Pytania: W Cart mamy CustomerID, czy zawsze wiemy jaki użytkownik wkłada produkty do koszyka? Bardzo często konto lub zapytanie o logowanie mamy dopiero na etapie zamówienia. Jak zrobić w takim razie transformację z anonimowej sesji do zalogowanego usera? Czy w Cart trzymamy wtedy ID sesji (jeśli to apikacja webowa) a w zamówieniu CustomerID to już będzie utworzone lub zalogowane konto? Czy może w Order będzie trzymane sessionID oraz customerID? Jak to ograć w CartCheckout wtedy?
czy planujecie wersje angielską kursu albo polecacie coś po angielsku?
Po przerobieniu waszego chciał bym pokazać coś równie dobrego reszcie zespołu a on niestety anglojęzyczny
Poczułem się mądry, bo skodziłbym ten model w podobny sposób ;)
Jednak problem jaki mam, to kiedy warto inwestować czas w lepszy model, jego odkrywanie i projektowanie (?), bo ja uważam, że zawsze, jednak PO z którymi zwykle mam do czynienia nie podzielają mojego entuzjazmu... Sprawa jest prosta z takim ecommerce, gorzej z projektami "w miarę nowymi", gdzie byty domenowe nie mapują się łatwo do archetypów, nie ma ekspertów, nie ma jednej wizji produktu, a PO twierdzi że nie ma sensu inwestować w zgrabny model póki użytkownicy nie zwalidują nam obecnej wersji produktu, bo jeszcze wszystko może się zmienić, nawet (a może zwłaszcza?) względem czegoś co zapowiada się na core :| Balans? Będzie coś o tym w kursie? Pewnie kupię i tak, bo robicie zajebistą robotę.
Myślę że w takiej sytuacji najlepszą rzeczą jaką można zrobić, to zdobyć jak najwięcej know-how z otoczenia biznesowego (kto jest/będzie naszym klientem, jaki problem rozwiązujemy, czym chcemy się wyróżniać etc.).
Następnie przygotował bym model good enough na bazie naszej wiedzy i skupiłbym się przede wszystkim na jego gotowości na zmiany (ewolucję lub rewolucję, zaleznie od realiów tego biznesu).
Można nawet pójść krok dalej i po tym modelu "good enough" zrobić PoC jakiegoś oczekiwanego kierunku rozwoju (rynek oczekuje X, rynek oczekuje Y etc).
Pamietajmy, że model odzwierciedla nasza obecna wiedze - a ta jak już wiesz jest niekompletna na poziomie organizacji.
Jak będzie wiadomo więcej to i model może dalej ewoluować. 😉
/Michau
Mam 1 problem z implementacją tego Cart'a mianowicie co jeśli użytkownik wyjdzie z widoku i wróci do niego za kilka minut, utworzy się nowy CheckoutCart, a poprzedni będzie stale i trzeba go będzie za każdym razem cron'em usuwać? Zakładam że musi wystąpić jakiś zapis, żeby klient po odświeżeniu strony(lub zmiany urządzenia) nie musiał za każdym razem wklepywać swoich danych
Fair point - przyklad jest oczywiście nieco okrojony by dalo się go w skończonym czasie pokazac i ogarnac (troche taki model, gdzie kontekstem problemu jest edukacja) 😉
Coś pominąłem czy umknął najciekawszy invariant, czyli blokowanie zakupu więcej niż jednego przedmiotu na kwartał?
W kolejnym materiale 😉
A po co jest 'id' w konstruktorze CheckoutCart? 1:11:31
Zabieram się za oglądanie, quality shit jak zwykle to można w ciemno napisać. Nurtuje mnie jednak jedna rzecz, skąd nagle ta moda na DDD? Przecież to jest podjeście, które istnieje już wiele lat. Teraz nagle cały yt (nie jest to zarzut w wasza strona, sam wsiadłem w ten hype-train a wiem, że z waszych materiałów dużo wyciągne) jest zalany DDD, tak samo w ofertach pracy coraz częściej wymagają tego podejścia. Wcześniej tak nie było.
Mysle że nałożyło się parę rzeczy: rośnie maturity branży i zaczynamy wszyscy rozumieć, że yet another framework nie zmienia tak znacząco niczego jeśli chodzi o sam biznes, dla którego budujemy rozwiazanie.
Poza tym w erze GPT-3 i GPT-4 (czy ogólnie LLM) próg wejścia do "technicznego" kodzenia maleje. I z tego miejsca są (imho) dwie drogi: stać się częścią zespołu produktowego i samego biznesu lub specjalizować się w bardzo niszowych tematach wymagających bardzo dużej wiedzy technicznej.
Oczywiście tak jak piszesz, DDD nie jest wcale nowe. Jego strategiczną część przynajmniej częściowo można podsumować słowami "najpierw myśl, potem rób". A jego taktyczna część to tak naprawdę "OOP done right". 😉
/Michau
Hmm, Order po zlozeniu moze byc zmodyfikowany , ale przez pracownika ;-) Bo jezeli zamowie 2x ten sam produkt, ale w magazynie sie okaze, ze jest tylko 1 to nie ma sensu anulowac calego zamowienia !
Pewnie, mówiliśmy chyba nawet o tym w materiale, ze ten case pominęliśmy. 😉
Żeby złapać całą domenę potrzeba paru godzin i szerszego kontekstu.
W sumie zmiane mozna tu ograć zachowując continuity, tzn. tworzyć zamówienie z zamówienia (niektóre sklepy tak robią, wystawiają nowe zamowienie i stare anuluja). 🤔
Inna sprawa ze brak w magazynie fizycznej "sztuki" bedzie do ogrania pewnie w zupelnie innym miejscu (Shipping?), komunikacja z klientem tez w innym miejscu, a taka przebudowa zamowienia (lub ponowne utworzenie) bedzie juz troche wynikiem.
/Michau
Wiadomo kiedy startuje kurs DDD w waszym wykonaniu?
Maj😃 Presale odpalamy w poniedziałek😉
ale ładny kadr ❤
Dzięki😃
Pytanie: Czy jesteście zaznajomieni z serią - Programuj z Beliarem?
kurła gościu dzięki, nie znałem go! dawno się tak nie uśmiałem :)
@@el3ndiill Nie ma za co :D
Kolega musi potrenować bicka bo ewidentnie tu nie pasuje... :P