Dostępy, package, struktura

1

Cześć,

otóż piszę sobie taki projekt ala bukmacher do szuflady. No i chcę dzielić to na moduły i spróbować zrobić to z użyciem praktycznie tylko package-scope.. No, ale... Mam problem w postaci takiej, że np. mam encję User i Bet - one mają między sobą relację.. Tak więc abym mógł użyć Bet w Userze musi być to albo PUBLIC albo muszą być w jednym package, ale nie zbyt mi się to pokrywa. No i tutaj pierwsze pytanie - jak to rozwiązać? Czy jeśli mam relacje na jakichś dwóch encjach to teraz muszą być one obowiązkowo w jednym package? Drugie sprawa to: podział na encje JPA, obiekty domenowe oraz DTO. Chciałbym dowiedzieć się jak tutaj podział powinien wyglądać i co dana rzecz ma w sobie zawierać.
Jak rozumiem encja JPA ma tylko i wyłącznie pola oraz @Entity nad sobą oraz relacje bazodanowe, DTO jest tylko potrzebne mi do jakiegoś ruchu na widok - tak abym nie musiał wybierać wszystkiego z bazy tylko brać DTO i to DTO pchać, czyli robię zazwyczaj select new dto(). No, a co z obiektem domenowym? Co on w sobie ma? Gdzie mogę coś o tym więcej przeczytać? Czy np. tam trzymam metody typu countOddValue() albo isActive() czy np. getWinnerOfEvent() gdzie mam jakieś podstawowe obliczenia? Czy raczej wciskam takie rzeczy w Service? Najbardziej mnie ciekawi właśnie co ma w sobie zawierać obiekt domenowy i jak dobrze rozplanować sobie strukturę takiego projektu.

Z góry dziękuję.

0

Usuwam poprzednią odpowiedz i teraz już całość. Tu mam bardzo podobny przykład do tego co mówisz. Kolejno:

Czy jeśli mam relacje na jakichś dwóch encjach to teraz muszą być one obowiązkowo w jednym package?
Nie. Załóżmy jak mówisz: pakiet Bet i User. Każdy z tych pakietów ma publiczną fasadę, która m. in. zwraca obiekty DTO (same dane). Wszystkie 'zasoby' (nie do końca są to zasoby ale można przyjąć takie uproszczenie) posiadają swoje id (najłatwiej UUID). I teraz w obiekcie Bet nie masz pola User user tylko UUID userId. Jeśli z jednego pakietu chcesz jakieś dane o obiektach z innego to masz ich id i pytasz tylko odpowiedniej fasady o potrzebne dane.

A teraz zastąp słowo pakiet mikroserwisem, fasadę klientem http, a DTO jsonami i już jesteś w świecie mikroserwisów :D

podział na encje JPA, obiekty domenowe oraz DTO. Chciałbym dowiedzieć się jak tutaj podział powinien wyglądać i co dana rzecz ma w sobie zawierać.
DTO: Dane które wysyłasz na front (czyli np w UserDTO nie będzie hasła)
Domenowe: obiekty które faktycznie coś robią na przykład w domenie bukmacherskiej przeliczanie wyników graczy po dodaniu wyniku meczów (czy tam meczy).
Service: No nie ma czegoś takiego. Znaczy jest ale nie do końca w takim rozumieniu jak w tutorialach.
Po pierwsze nazwa Service nikomu nic nie mówi. Po drugie jeśli się zastanowisz co taki service powinien robić to dojdziesz do wniosku ze to samo co obiekty domenowe. Załóżmy ze chcesz zobaczyć czy liga jest zarchiwizowana. Typowy przebieg wygląda mniej więcej tak:

  1. Przychodzi request do kontrolera
  2. Kontroler przekazuje request do fasady (isLeagueArchived(UUID leagueId))
  3. Fasada pobiera z repozytorium (o tym można by osobny punkt) obiekt domenowy. (Dostaje obiekt League)
  4. W obiekcie domenowym robisz faktyczne operacje (league.isArchived())
  5. Fasada zwraca wynik do kontrolera
  6. Kontroler mapuje wynik na odpowiedz http

Gdzie mogę coś o tym więcej przeczytać?
No tu już jest lekka bieda. Na pewno ta prezentacja oraz poczytaj o architekturze heksagonalnej aka porty i adaptery

0

O, ten przykład wiele pomaga. Co do architektury heksagonalnej to właśnie się w to zagłębiam, bo bardzo ciekawy temat.. Całkowicie inne spojrzenie niż do tej pory.
Ten projekt trochę mi to obrazuje jak się za to zabrać i jak to wszystko łączyć, wielkie dzięki za taką długą odpowiedź.

Jak będą jeszcze jakieś problemy - a na pewno będą to zgłoszę się z kolejnymi pytaniami :D

ps. ten package "query" to też CQRS, tak?

1

Czy jeśli mam relacje na jakichś dwóch encjach to teraz muszą być one obowiązkowo w jednym package?
Nie. Załóżmy jak mówisz: pakiet Bet i User. Każdy z tych pakietów ma publiczną fasadę, która m. in. zwraca obiekty DTO (same dane). Wszystkie 'zasoby' (nie do końca są to zasoby ale można przyjąć takie uproszczenie) posiadają swoje id (najłatwiej UUID). I teraz w obiekcie Bet nie masz pola User user tylko UUID userId. Jeśli z jednego pakietu chcesz jakieś dane o obiektach z innego to masz ich id i pytasz tylko odpowiedniej fasady o potrzebne dane.

@danek a wiesz że to powoduje powstanie problemu N+1? Nie neguje sensu stosowania fasad tego typu ale zwracam uwagę ;)

1 użytkowników online, w tym zalogowanych: 0, gości: 1