Obiekty encji z package access

Hej,
pisze aktualnie niedużą apkę w zasadzie realizującą jedną funkcjonalność, Chciałem jednak przećwiczyć sobie hermetyzację i wdrażanie innego podziału pakietów niż controller/service/domain. Mam trzy encje, z czego jedna z nich posiada relacje @ManyToOne z dwoma pozostałymi. Pomyślałem sobie, że dobrze będzie obiekty encji zamknąć w pakietach i nadać im dostęp prywatny, a po pobraniu z bazy od razu mapować na DTO (dodawać jeszcze obiekty domenowe moim zdaniem to troche za duzo, jak na scope tej apki). Problem pojawił się jednak już w momencie definiowania tych obiektów. W Encji Result posiadającej relacje z pozostałymi encjami IDE nie może ziamportować reszty klas, gdyż właśnie mają ustawiony dostęp prywatny.
Chciałem zrobić to tak, by każda z tych encji była pozamykana w osobnym pakiecie, wraz ze Springowym @Repository, publicznym DTO, które to już będzie sobie latało po warstwie biznesowej apki i jakąś publiczną fasadą pełniącą rolę abstrakcji nad repository. W głowie mi to wyglądało jak złota inżynieria, ale w trakcie implementacji czuję, że wpadam w jakąś głupią pułapkę zastawioną przez samego siebie.

Wobec tego proszę Was o jakąś pomoc w nakierowaniu mnie na właściwy tor, gdyż czuję że albo jestem bliski przeinżynierowania tego, albo w ogóle źle o tym myśle. Najłatwiej byłoby mi zaprojektować tą apke w klasycznym studenckim podziale warstwowym, ze względu na wspomnianą wczesniej jedną funkcjonalność, ale chce się trochę od tego odzwyczaić, z racji że studia skończone :D i trzeba przyjąć inną architekturę

Wydaje mi się że jeżeli naprawdę potrzebujesz tej relacji w module to najlepszą opcją będzie zrobienie dwóch encji do tej samej tabeli, dedykowanych odpowiednim pakietom. Kluczowe pytanie: czy potrzebujesz tych relacji w formie "klasowej" czy może po samych identyfikatorach wystarczy? Przecież możesz mieć relacje nie implementując tego w formie klas a longów/integerów. Nasuwa się też pytanie: czy jeżeli twój moduł jest tak silnie ze sobą powiązany to czy nie powinien być jednym? Co będzie oznaczało punkt wyjścia do upakowania wszystkiego w jeden kontekst/moduł.

Hmm, pierwsze słyszę o takim pobieraniu obiektów powiazanych w relację poprzez id. Czy tego sie dokonuje poprzez jakies preparedStatement i rowMappery?

Mi się wydaje że własnie wydaje że tutaj zrobiłes znaczne przekombinowanie, jak to się mówi overkill ;) Powiązane encje/obiekty domenowe/dto powinny być w jednym module

Referencje do innych obiektów po samym id bierze się jak mniemam z inspiracji DDD i agregatami. Jeden agregat może odwoływać się do innego tylko przez id. Taka zasada komplikuje kod, aby rozwiązać inne problemy takie jak np. zasięg transakcji, a co za tym idzie - wydajność. W Twoim przypadku to pewnie overengineering, natomiast jeśli piszesz to dla siebie, to dlaczego nie spróbować. Polecam zerknąć tutaj https://github.com/VaughnVernon/IDDD_Samples i przeczytać https://www.amazon.com/Implementing-Domain-Driven-Design-Vaughn-Vernon/dp/0321834577

Jeśli masz encje w osobnych pakietach to one nie powinny o sobie wiedzieć. Jeśli mają o sobie wiedzieć to powinny być w jednym pakiecie ;)

danek napisał(a):

Jeśli masz encje w osobnych pakietach to one nie powinny o sobie wiedzieć. Jeśli mają o sobie wiedzieć to powinny być w jednym pakiecie ;)

No właśnie przyznam się @danek, że w całą tą karuzelę myślenia wpadłem inspirując się Twoim githubem i pewnym repo, gdzie masz obiekty domenowe package private, co prawda bez żadnych adnotacji, ale odwołujesz się tam chyba z tego co pamiętam do obiektów w relacjach poprzez UUID. Zainspirowało mnie to właśnie do schowania obiektów encji w pakietach i transformowanie ich od razu na takie obiekty domenowe/DTO i operowanie na nich w warstwie serwisowej. Może rzeczywiście najlepiej będzie, jak zapakuję całą domenę do jednego pakietu, wszak to tylko trzy encje powiązane ze sobą. Całe mięsko apki i tak polega na tym żeby te dane później odpowiednio przetransformować.

Belka napisał(a):

danek napisał(a):

Jeśli masz encje w osobnych pakietach to one nie powinny o sobie wiedzieć. Jeśli mają o sobie wiedzieć to powinny być w jednym pakiecie ;)

No właśnie przyznam się @danek, że w całą tą karuzelę myślenia wpadłem inspirując się Twoim githubem i pewnym repo, gdzie masz obiekty domenowe package private, co prawda bez żadnych adnotacji, ale odwołujesz się tam chyba z tego co pamiętam do obiektów w relacjach poprzez UUID. Zainspirowało mnie to właśnie do schowania obiektów encji w pakietach i transformowanie ich od razu na takie obiekty domenowe/DTO i operowanie na nich w warstwie serwisowej. Może rzeczywiście najlepiej będzie, jak zapakuję całą domenę do jednego pakietu, wszak to tylko trzy encje powiązane ze sobą. Całe mięsko apki i tak polega na tym żeby te dane później odpowiednio przetransformować.

Najważniejsze pytanie brzmi co to są za encje, bo jeżeli próbujesz na moduły rozbić coś co jest logicznie ze sobą powiązane i powinnno być w jednym module, a shackujesz sobie to w ten sposób że dwie encje będą posiadały referencje po IDku (mam na mysli klasy w javie) to robisz sobie wielką krzywdę i generalnie to niczego nie przecwiczysz i niczego sie nie nauczysz