Zgodnie z zasadami czystej architektury encje biznesowe powinny być oddzielone od encji JPA, ale spotkałem się też z odwrotnym podejściem. Co o tym myślicie i w jaki sposób oddzielacie te dwie rzeczy, oczywiście jeśli je w ogóle rozróżniacie i używacie Hibernata.
0
2
W teorii powinno się rozdzielać, w praktyce nigdy nie widziałem, żeby to ktoś robił ;) nie zawsze to ma sens. Najważniejszy jest złoty środek, świat nie jest czarno-biały. Obejrzyj na YT prezentacje Łukasza Szydło na ten temat.
4
Przestań używać JPA to wtedy zostaną Ci same encje domenowe / biznesowe i dylemat z głowy. To jak później to zapiszesz na bazie to zostaje "do doprecyzowania" - elastyczne sobie możesz wybrać czy JDBC czy inne JOOQ.
Widziałem geniuszy którzy robią z encji JPA, encje biznesową która jest współdzielona przez wszystkie moduły i chyba tylko tona złota przekonałaby mnie aby pracować w takim projekcie.
1
Oddzielać, chyba że robisz CRUDa i masz w zasadzie tylko jeden model który mapujesz json<->db i lecisz encja na twarz i pchasz
Jeśli masz cokolwiek więcej to brak oddzielenia szybko sprawi że będziesz cudować z jakimiś @Transient albo z nazwami metod żeby hibernate nie próbował ich dotykać, i będziesz się kisić w jakimś krzywym modelu który ci nie pasuje, bo nie możesz tam niczego dodać, bo nie pasuje do tego co jest w bazie. Generalnie to bolesne i nie ma sensu.
Najlepiej w ogóle pozbyć się JPA i tworzyć od razu obiekty domenowe. JPA w zasadzie nic ci nie daje - wyciągasz z bazy to DTO @Entity i zaraz je przemapowujesz na obiekt domenowy. Albo w drugą stronę, generujesz sobie taki obiekt z obiektu domenowego żeby zawołać .save(obj). Więc jaki jest sens tych wszystkich klas które mapują ci tabele? :)