Cześć!
Aktualnie piszę projekt sam dla siebie żeby poćwiczyć JPA, Springa. Nie jestem pewien czy idę w dobrym kierunku. W tym momencie piszę backend który potem chcę spiąć z React. Czy moja struktura projektu jest poprawna? UserEntiy konwertuję na zwykłego Usera żeby łatwiej było zarządzać danymi.
Jeżeli masz encje w infrastrukturze, to coś jest niehalo. Poza tym nie ma czegoś taka jak „poprawna struktura” - wszystko zależy co chcesz osiągnąć. No dobra - wrzucenie wszystkiego do głównego pakietu byłoby na pewno słabe :)
@Charles_Ray: Chcę oddzielić encje. Po pobraniu z bazy przekształcać je w zwykłe obiekty i nimi manipulowac nastepnie obiekty znow przekształcać w encje.
Bez jakichś bardziej rozbudowanych informacji trudno oceniać strukturę tak jak już napisał @Charles_Ray . Napisz w jakim kierunku planujesz iść z architekturą, jaką wielkość aplikacji planujesz, na jaką strategie mapowania się zdecydowałeś, czy zastanawiałeś się czy w Twojej aplikacji dane mapowanie ma faktycznie sens czy będziesz tylko przerzucał DTO w prawo i lewo etc. Na razie to tylko widać strukturę plików, która ma w sumie znaczenie estetyczne.
Duża ilość pakietów wcale nie pomaga w lepszej organizacji kodu aplikacji a nawet przeszkadza, bo klasy, które powinny być de facto w jednym pakiecie, bo należą do tego samego kontekstu , są rozsiane po jakiś oddzielnych małych i często zagnieżdżonych pakietach, przez które trzeba się ciągle przeklikiwać. Druga sprawa to łamanie enkapsulacji, bo jak masz mnóstwo małych pakietów ze źle określonym kontekstem, które ze sobą rozmawiają, to siłą rzeczy praktycznie każda klasa musi być publiczna zmiast package private i wystawiać tylko jakieś publicze api.Dlatego warto się zastanowić czy naprawdę jest potrzebny kolejny pakiet i wystrzgać się pakietozy, która trawi pewnie nie jedną apkę.
Polecam ci w tym temacie prezentację Jakuba Nabrdalika:
Nie kupuje takiego rozdzielnia encji w sensie pakietów. Sens podziału aplikacji na moduły/ficzery jest m. in. taki, żeby mieć wszystkie powiązane rzeczy blisko siebie unikając śmietnika (big ball of mud). Jaki jest zatem sens mieć Usera i UserEntity 10 pakietów dalej? Takie szczypanie się nic nie wnosi, a tylko wprowadza niepotrzebna komplikację. Potem się wszyscy śmieją, że „ooo DDD jest dla purystów i nic nie daje”. To powinno być wszystko w jednym module „uaa” (user authentication & authorization), „user”, „auth”, czy jak chcesz to zgrabnie nazwać.
struktura jest jak dziura w d..., każdy ma swoją
ja bardzo nie lubię kodu podzielonego na moduły per warstwa architektury
o wiele lepiej mi gdzy kod podzielony per funkcja (use case) i tam dopiero dzielisz per warstwa
https://github.com/Pharisaeus/almost-s3 nie mówie że to najlepsza struktura, ale sprawdza się całkiem dobrze ;)
@Maciek G: zajrzyj do tej książki https://reflectoring.io/book/ - można ją kupić po taniości, a jest bardzo fajną pozycją. Nie jest stricte o DDD, ale hexy zazwyczaj są używane w DDD, więc znajdziesz wiele odpowiedzi na swoje pytania + kilka pytań, na które jeszcze sobie nie odpowiedziałeś. Książka jest krótki i prosto napisana, więc w 1-2 dni można ją przeczytać ze zrozumieniem.
Co do struktury proponowanej przez autora tej książki, to wygląda ona tak (wersja dla proty/adaptery, czyli coś co często stosuje się w DDD): https://imgur.com/AdWtchg
Nawet jeśli nie idziesz w kierunku porty/adaptery to nadal myślę, że na podobnej strukturze możesz bazować jako punkt wyjścia. Masz jednak o wiele ważniejsze decyzje do podjęcia niż struktura plików. Co jeszcze mi się rzuca w oczy to, że idziesz w kierunku DDD, a nie masz na przykład ani śladu ValueObjectów, a to dla mnie taka chyba integralna część DDD (wiem, wiem - można się z tym kłócić).
Pytanie też o duplikowanie obiektów typu User i UserEntity - nie da się tego w Javie ogarnać jakimś ORM wspierającym Data Mapper Pattern? Pytam, bo nie znam Javy, a trochę tak to wygląda jakby UserEntity było ActiveRecordem i potem byś to mapował na obiekty biznesowe.
Java 
Spring 
domain. W infrze ma UserEntity, a w domain User.