Dostępy, package, struktura

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

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?

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ę ;)