- Załóżmy że mam moduł A i B. - Oba moduły posiadają model „Product” (który ma oczywiście inną definicję w A i B). - Oba moduły korzystają z bazy postgres. W wideo mówisz aby zacząć sobie od logicznego wydzielenia w bazie schema’y per moduł 14:49 . Moje rozmyślenie jest aby jeszcze bardziej sobie to uprościć i utworzyć jedną scheme w której jest tylko jedna tabelka „Product”? Fakt, „Product” będzie zawierać więcej pól, ale moduł może sobie wyciągać pola, które „są dla niego” Ogólnie super materiał, dzięki :)
Dodaj do tego modul C i D i wpadamy w problem modelu kanonicznego. :) Mówimy (z tego co pamietam) o tym trochę w materiale na YT pt. "Czym jest model?" jak i bardziej kompleksowo w kursie Domain-Driven Design Pragmatycznie. /Michau
Doszedłem aktualnie do podobnych przemyśleń co wy w zaprezentowanym materiale. Jedyne z czym mam problem to cyrkularne zależności (w .net problem pojawi się przy dodawaniu referencji do projektu, w nestjs w runtimie). Rozwiązaniem jest wydzielenie wspólnej warstwy komunikacyjnej (projekt w .net) gdzie każdy moduł rejestrowałby swoją implementację wewnętrznego api.
W najbliższym materiale, związanym z częścią praktyczną modularnego monolitu, pokażemy, jak można zaaplikować alternatywne podejście do komunikacji pomiędzy modułami, bez konieczności tworzenia współdzielonych projektów :)
Czy uważacie, że w pierwszej kolejności zaznajomienie się z kursem Becoming a software dev na kanale Piotrka i później przyswajanie aktualnych wiadomości z waszego kanału to efektywny sposób nauki?
Jeżeli chcesz się zapoznać z samym językiem, podstawowymi wzorcami projektowymi, OOP, to poruszone w nim pojęcia są w miarę aktualne (oczywiście teraz, niektóre rzeczy pewnie zostałyby zrobione trochę inaczej). Trzeba mieć tylko z tyłu głowy, że kurs bazuje na pierwszych wersjach .NET Core, więc w kontekście frameworka to trochę od tamtego czasu się pozmieniało :)
Samo bierne oglądanie/czytanie czegokolwiek nie jest efektywnym sposobem nauki. Dodatkowo do pewnej wiedzy "trzeba dorosnąć". Co komuś da czytanie i wzorcach projektowych jeśli np. nie potrafi napisać prostej apki konsolowej za pomocą prawdziwego OOP?
@@ArekTheBoss jasna sprawa, analogicznie jak z nauką języka lub czegokolwiek innego - praktyka jest bardzo ważna. Z drugiej strony, nierzadko ludzie się rzucają na wymagające wzorce architektoniczne nie mając solidnych fundamentów :)
@@DevMentorsPL dlatego ja staram się wszystko stopniować i dobierać do poziomu doświadczenia. Do dziś pamiętam, jak na wakacjach w Grecji, nad basenem czytałem sobie clean code (wtedy jeszcze na sporo przed podjęciem pierwszej pracy) jak się okazało, niewiele z tego wtedy rozumiejąc ;)
Rzeczowo, krótko i na temat. Znakomity materiał.
Dziękujemy! :)
mega!!
- Załóżmy że mam moduł A i B.
- Oba moduły posiadają model „Product” (który ma oczywiście inną definicję w A i B).
- Oba moduły korzystają z bazy postgres.
W wideo mówisz aby zacząć sobie od logicznego wydzielenia w bazie schema’y per moduł 14:49 .
Moje rozmyślenie jest aby jeszcze bardziej sobie to uprościć i utworzyć jedną scheme w której jest tylko jedna tabelka „Product”?
Fakt, „Product” będzie zawierać więcej pól, ale moduł może sobie wyciągać pola, które „są dla niego”
Ogólnie super materiał, dzięki :)
Dodaj do tego modul C i D i wpadamy w problem modelu kanonicznego. :)
Mówimy (z tego co pamietam) o tym trochę w materiale na YT pt. "Czym jest model?" jak i bardziej kompleksowo w kursie Domain-Driven Design Pragmatycznie.
/Michau
@@DevMentorsPL dzięki za odpowiedź! Muszę zgłębić temat w takim razie
DDD strategicznie kupuję w ciemno ;)
No i znowu kozak materiał.
Dzięki! Za tydzień kontynuacja z częścią praktyczną i kodem :)
Doszedłem aktualnie do podobnych przemyśleń co wy w zaprezentowanym materiale. Jedyne z czym mam problem to cyrkularne zależności (w .net problem pojawi się przy dodawaniu referencji do projektu, w nestjs w runtimie). Rozwiązaniem jest wydzielenie wspólnej warstwy komunikacyjnej (projekt w .net) gdzie każdy moduł rejestrowałby swoją implementację wewnętrznego api.
W najbliższym materiale, związanym z częścią praktyczną modularnego monolitu, pokażemy, jak można zaaplikować alternatywne podejście do komunikacji pomiędzy modułami, bez konieczności tworzenia współdzielonych projektów :)
@@DevMentorsPL Jeszcze takie pytanie, w czym robicie grafiki?
@@jamnikowy_piechur1230 Canva
Czy uważacie, że w pierwszej kolejności zaznajomienie się z kursem Becoming a software dev na kanale Piotrka i później przyswajanie aktualnych wiadomości z waszego kanału to efektywny sposób nauki?
Jeżeli chcesz się zapoznać z samym językiem, podstawowymi wzorcami projektowymi, OOP, to poruszone w nim pojęcia są w miarę aktualne (oczywiście teraz, niektóre rzeczy pewnie zostałyby zrobione trochę inaczej). Trzeba mieć tylko z tyłu głowy, że kurs bazuje na pierwszych wersjach .NET Core, więc w kontekście frameworka to trochę od tamtego czasu się pozmieniało :)
Samo bierne oglądanie/czytanie czegokolwiek nie jest efektywnym sposobem nauki. Dodatkowo do pewnej wiedzy "trzeba dorosnąć". Co komuś da czytanie i wzorcach projektowych jeśli np. nie potrafi napisać prostej apki konsolowej za pomocą prawdziwego OOP?
@@ArekTheBoss jasna sprawa, analogicznie jak z nauką języka lub czegokolwiek innego - praktyka jest bardzo ważna. Z drugiej strony, nierzadko ludzie się rzucają na wymagające wzorce architektoniczne nie mając solidnych fundamentów :)
@@DevMentorsPL dlatego ja staram się wszystko stopniować i dobierać do poziomu doświadczenia. Do dziś pamiętam, jak na wakacjach w Grecji, nad basenem czytałem sobie clean code (wtedy jeszcze na sporo przed podjęciem pierwszej pracy) jak się okazało, niewiele z tego wtedy rozumiejąc ;)
@@ArekTheBoss dobre podejście :D