Możesz też trzymać ten interfejs w pakiecie dao nie jest to zabronione, ani w żaden sposób narzucone przez jakieś reguły, chociaż nie zawsze ma to sens.
W tym przypadku wydało mi się, że bardziej sensowne będzie trzymanie go w tym miejscu. Zanim zacząłem dodawać ten interfejs, powiedziałem, że w takiej małej aplikacji dodawanie tego interfejsu nie ma za bardzo sensu, bo tak naprawdę nie potrzebujemy tej abstrakcji. Chciałem tylko zademonstrować, jak by to wyglądało.

W dużej aplikacji, gdzie taka abstrakcja byłaby już (może) przydatna. Taki interfejs raczej nie znajdowałby się w tym samym pakiecie wraz z implementacją. Tylko np. znajdowałby się w pakiecie z domeną, a implementacja znajdowałaby się w pakiecie z infrastrukturą (tak jak jest to w architekturze Heksagonalnej).

Interfejs wprowadza abstrakcję. Czyli oddziela implementację od interfejsu klasy. Dzięki temu możesz używać interfejsu klasy i jej implementacji osobno (Wiec, dlaczego trzymać to razem?).

W tym przypadku tak naprawdę nie ma to znaczenia, jedni będą trzymali w dao inni gdzie indziej.

Co do fasady, to dao tak naprawdę jest fasadą dla EntityManagera. Czy chciałbyś jeszcze robić dodatkową fasadę do tego? Wydaje mi się to bardzo nadmiarowe.

Dzięki za komentarz i miłe słowa 😉
Jeśli chodzi o pytania to:

Ad.1. Dao to nie repozytorium. Inaczej implemntuje się wzorzec dao inaczej repozytorium, więc nazywanie dao repozytoriu to błąd. Ale rozumiem, że tylko używacie adnotacji @Repository w Dao. I to nie jest jakiś duży błąd, co najwyżej błąd semantyczny (ja raczej tak nie robię, dlatego tak powiedziałem w filmie). Można zrobić własną adnotację i trochę to poprawić. Nie powiedziałem o tym, ale można zrobić adnotację @Dao (czy jakąś inną) i używać jej jak każdej innej adnotacji springowej, do tworzenia beanów. Musi ona tylko dziedziczyć po adnotacji np. @Component. I chyba być w miejscu, gdzie działa component scan(nie pamiętam dokładnie).

Ad.2. Jeśli chodzi o wstrzykiwanie to powinno być private final. Czasem podczas nagrywania zapominam o rzeczach, o których normalnie nigdy nie zapominam 😉

Ad.3. Dependency Inversion Principal – trudno powiedzieć gdzie stosować, a gdzie nie, dlatego trudno byłoby zrobić jakiś materiał o tym. Na pewno w większych systemach, gdzie będziesz miał dużo integracji z różnymi usługami, narzędziami, tam warto te narzędzia oddzielać od systemu, gdzie domena jest trochę bardziej skomplikowana, tam warto ją oddzielić od innych elementów systemu. Na pewno w małych aplikacjach CRUD nie będziesz miał z tym problemu. Natomiast zawsze jest tak, że im więcej kodu tym pojawia się więcej różnych problemów. I DIP jest jednym ze sposobów, żeby te problemy ogarniać, ale to jeden z setki takich sposobów, których będziesz uczył się przez lata 😉 Zapraszam też do warsztatu o architekturze heksagonalnej, która właściwie jest na tym zbudowana, gdzie domena jest oddzielona od reszty systemu. Tam jest to pokazane na przykładzie architektury.

Podczas oglądania filmiku nasunęło mi się parę pytań:

1. W moim obecnym projekcie do niedawna obowiązywał głównie wzorzec DAO (teraz trwa migracja właśnie na Hibernate i jego repositories) – dostęp do danych był realizowany przy użyciu technologii QueryDsl. Klasy DAO, np. RequestDao, StepDao itp. są u mnie mimo wszystko oznaczone adnotacją „@Repository”, mimo że stricte repozytorium nie są – w materiale (okolice 45:51) nad klasą ProductDao umyślnie umieściłeś adnotację „@Component”, tłumacząc że „nie mamy w Springu adnotacji @Dao, więc korzystamy z adnotacji @Component” – pytanie brzmi czy w takim razie umieszczenie „@Repository” nad klasą DAO jest jakiegoś rodzaju błędem lub mylącą praktyką? DAOsy są niejako w zastępstwie repozytoriów, dlatego nie widziałem w tym do tej pory nic sprzecznego, natomiast patrząc jak wyżej to przedstawiłeś pojawiło mi się w głowie takie pytanie.

2. U mnie w projekcie wstrzykiwane pola są deklarowane jako „private final”, w materiale deklarujesz je tylko jako „private” -> wydaje mi się, że forma „private final” jest preferowana, nie wiem czy opuściłeś „final”, żeby nie wprowadzać dodatkowego zamieszania do kodu, czy jest jakiś inny powód?

3. To już może nie pytanie, a sugestia na artykuł/warsztat/kurs w przyszłości – zastanowiło mnie w jakich konkretnie przypadkach Dependency Inversion Principal jest korzystne do użycia. Wydaje mi się że w materiale padało tylko „w niektórych przypadkach DIP jest warto wykorzystać'”, ale nie był to temat rozwinięty, ale może coś pominąłem.

Dzięki z góry za odpowiedzi i pozdrawiam,
Kacper

Jasne, można jak najbardziej stworzyć moduły gradlowe, czy w mavenie mavenowe. Wspomniałem o tym gdy mówiłem o wadach tej architektury (tuż przed kodowaniem).
W warsztacie nie pokazywałem, tego na modułach, bo trochę zaciemniają one strukturę aplikacji (przynajmniej z mojej perspektywy osoby opowiadającej o tym), a chciałem, żeby ten podział był dobrze widoczny w warsztacie i bardzo przejrzysty. Myślę, że przerobienie tego na moduły to nie jest duży problem i każdy powinien sobie z tym poradzić. Jeśli trzeba to mogę pomóc 😉

Jasne. Ja zawsze powtarzam, że trzeba mapować tam, gdzie jest taka potrzeba. Jak nie ma potrzeby, to często jest to tylko sztuka dla sztuki, albo wymusza to jakaś odgórnie przyjęta konwencja/architektura. Wszystko trzeba robić z głową 😉

Oczywiście w prostych aplikacjach nie będzie to miało za bardzo sensu, ale też w takich aplikacjach nie stosuje się architektury heksagonalnej. Natomiast w większych aplikacjach, to często tak po prostu wychodzi. Encja nie jest taka sama jak klasa modelu (wiec musisz przemapować), a na końcu nie możesz pokazać całej zawartości klasy modelu w endpoincie i też musisz przemapować na dto.

W warsztacie może tego jakoś specjalnie nie widać, bo bardziej przedstawiam to jako założenia tej architektury, ale w dużych aplikacjach, gdzie model domenowy jest skomplikowany, gdzie technicznie aplikacja też jest skomplikowana, takie podejście to norma niezależnie od architektury. Gdy masz aplikację, która używa bazy danych, do tego kilku webserwisów, to cały czas musisz mapować z jednych obiektów na inne.

Oczywiście, jeśli nie potrzebujesz mapowania, to nie rób go na siłę, bo to strata czasu i energii.