Fajny materiał 👍 Mam wrażenie, że jest tutaj jednak pewna nieścisłość. Controller odbierający żądania http powinien wg mnie być w warstwie infrastruktury i nie wywoływać akcji bezpośrednio na obiektach domenowych tylko delegować akcje do serwisu aplikacyjnego (use case) znajdującego się w warstwie aplikacji. W serwisie aplikacyjnym właśnie powinien być kod odpowiedzialny za sklejenie procesu czyli pobranie obiektow z bazy, wykonanie na nich akcji, zapisanie do bazy itp. To powoduje, że jeśli obok żądań http będziemy tworzyć zamówienie w reakcji na np. event z kolejki lub inny endpoint to nie będziemy powtarzać tych samych akcji w każdym z tych miejsc. W każdym razie - samo przedstawienie idei odwrócenia zależności i czystej domeny - super 👍
Mass rację, tak to powinno wyglądać :) Będę o tym opowiadał w kolejnych częściach dotyczących właśnie warstw Aplikacji i UserInterface/Presentation. Skupiam się po kolei na każdej z warstw, żeby film był kompletny ale nie zbyt obszerny.
Jestem w zespole SRE ale mam ogólnie interesuje mnie wszystko i tak trafiłem na Twój kontent. Podrzuciłem naszym developerom - nawet nie przyznali że nic z tego nie rozumieją tylko zlali. Jak ten development ma się rozwijać?
Miałem styczność z czymś takim i ciężko to niestety przeskoczyć. Każdy z nas jest inny - jedni chcą się rozwijać i uczyć, innych zadowala to co mają. Jeśli chcesz to napisz do mnie na LinkedIn, podrzucę Ci trochę info jak można spróbować rozruszać zastygłe tryby w firmie :) Pamiętaj, że to tylko sugestie, i nie w każdej sytuacji mogą zadziałać, to zależy od człowieka z którym masz styczność :)
kurde, ja siedze w aplikacji 13sto letniej, napisanej w zend 1 oraz laminas :D i mimo to, że to tak potężne legacy to w każdym module nowy kod wyciągamy jak tylko się da do warstw właśnie :) aplikacja, domena, infra - jedynie kontrolery trzymamy w starym miejscu :) Podział kontextów jest ubogi, bo bazujemy na modułach wydzielonych przez rzeczowniki (czyli moduł = tabelka w bazie :) ) a nie wydzielonych na zachowaniach. No ale tak czy siak, bez bounded contextów nowy kod i ląduje z pdziałem na warstwy, które są pisane w 100% w oderwaniu od frameworka, czyste php :) Da się, tylko trzeba chiceć :)
@@adambanaszkiewicz 14:54 metoda _addToCart_ korzysta ze zmiennej _repository_. _repository_ jak i kiedy zainicjowane, jak przekazane do _addTo_Cart_ tak żeby odpowiadało konkretnej instancji _MysqlCartRepository_ ? Na niewtajemniczonym w Clean Architecture robi to spore wrażenie ;)
Teraz rozumiem. Wszystko zależy od języka i frameworka w którym piszesz. W większości będzie to wyglądało tak samo, czyli definiujesz serwis z nazwą interfejsu, ale z instancją klasy. Symfony zrobi to w sumie za nas gdy zrobimy autowire i gdy jest tylko jedna implementacja interfejsu. Nie chciałem dodawać zbyt dużo szczegółów do repozytorium by go nie "rozwodnić" zbytnio. Napisz do mnie na LinkedIn albo na FB, pociągniemy temat dalej jeśli jesteś zainteresowany :)
Keep up the good job!
T. Hanks :)
Fajny materiał 👍 Mam wrażenie, że jest tutaj jednak pewna nieścisłość. Controller odbierający żądania http powinien wg mnie być w warstwie infrastruktury i nie wywoływać akcji bezpośrednio na obiektach domenowych tylko delegować akcje do serwisu aplikacyjnego (use case) znajdującego się w warstwie aplikacji. W serwisie aplikacyjnym właśnie powinien być kod odpowiedzialny za sklejenie procesu czyli pobranie obiektow z bazy, wykonanie na nich akcji, zapisanie do bazy itp. To powoduje, że jeśli obok żądań http będziemy tworzyć zamówienie w reakcji na np. event z kolejki lub inny endpoint to nie będziemy powtarzać tych samych akcji w każdym z tych miejsc.
W każdym razie - samo przedstawienie idei odwrócenia zależności i czystej domeny - super 👍
Mass rację, tak to powinno wyglądać :) Będę o tym opowiadał w kolejnych częściach dotyczących właśnie warstw Aplikacji i UserInterface/Presentation. Skupiam się po kolei na każdej z warstw, żeby film był kompletny ale nie zbyt obszerny.
@@adambanaszkiewicz ok 👍 w takim razie wybiegłem trochę wprzód 😄
Powodzenia w tworzeniu kanału! 👍
Jestem w zespole SRE ale mam ogólnie interesuje mnie wszystko i tak trafiłem na Twój kontent. Podrzuciłem naszym developerom - nawet nie przyznali że nic z tego nie rozumieją tylko zlali. Jak ten development ma się rozwijać?
Miałem styczność z czymś takim i ciężko to niestety przeskoczyć. Każdy z nas jest inny - jedni chcą się rozwijać i uczyć, innych zadowala to co mają. Jeśli chcesz to napisz do mnie na LinkedIn, podrzucę Ci trochę info jak można spróbować rozruszać zastygłe tryby w firmie :) Pamiętaj, że to tylko sugestie, i nie w każdej sytuacji mogą zadziałać, to zależy od człowieka z którym masz styczność :)
kurde, ja siedze w aplikacji 13sto letniej, napisanej w zend 1 oraz laminas :D i mimo to, że to tak potężne legacy to w każdym module nowy kod wyciągamy jak tylko się da do warstw właśnie :) aplikacja, domena, infra - jedynie kontrolery trzymamy w starym miejscu :) Podział kontextów jest ubogi, bo bazujemy na modułach wydzielonych przez rzeczowniki (czyli moduł = tabelka w bazie :) ) a nie wydzielonych na zachowaniach. No ale tak czy siak, bez bounded contextów nowy kod i ląduje z pdziałem na warstwy, które są pisane w 100% w oderwaniu od frameworka, czyste php :) Da się, tylko trzeba chiceć :)
@@DanielŚmigiela Jak są ludzie którzy chcą coś zmienić to jest więcej niż pół sukcesu :)
Jako amator, hobbysta... przydałoby się parę słów o DI bo to _repo_ to na razie "under the hood"/"behind the scene"
Mógłbyś bardziej rozwinąć co masz na myśli? Czego byś potrzebował?
@@adambanaszkiewicz 14:54 metoda _addToCart_ korzysta ze zmiennej _repository_. _repository_ jak i kiedy zainicjowane, jak przekazane do _addTo_Cart_ tak żeby odpowiadało konkretnej instancji _MysqlCartRepository_ ? Na niewtajemniczonym w Clean Architecture robi to spore wrażenie ;)
Teraz rozumiem. Wszystko zależy od języka i frameworka w którym piszesz. W większości będzie to wyglądało tak samo, czyli definiujesz serwis z nazwą interfejsu, ale z instancją klasy. Symfony zrobi to w sumie za nas gdy zrobimy autowire i gdy jest tylko jedna implementacja interfejsu.
Nie chciałem dodawać zbyt dużo szczegółów do repozytorium by go nie "rozwodnić" zbytnio. Napisz do mnie na LinkedIn albo na FB, pociągniemy temat dalej jeśli jesteś zainteresowany :)
@@adambanaszkiewicz Dzięki za odpowiedź. Roztrząsanie tego wątku w rzeczy samej zaciemniłoby jasność przekazu w materiale.