Ja bym to jednak dzielił trochę inaczej. Mniej dziedzinowo a bardziej funcjonalnie -> np. modułami niech będą kolejne "warstwy" aplikacji.
Ok, czyli proponujesz cos na zasadzie:
- warstwa dostepu do danych (encje, repozytoria itd).
- warstwa logiki biznesowej (servisy itd)
- warstwa gui
Dobrze rozumiem?
@tk, zle podejście. Dzielisz moduły funkcjonalnie na poziomie mavena, ale nie na poziomie projektu. Inne podejście. Jeżeli moduł np. raportow potrzebuje danych z magazynu to niech pyta się o te dane za pomocą jakiegoś interfejsu. Oczywiście najprościej by dostał "gołe" dane na przykład chcesz mieć raport stan magazynu na koniec miesiąca. To moduł raportowy uderza do magazymy o stan na datę. Dostaje (przykładowo) mapę na ktorej już sobie pracuje.
Wbrew pozorom nie chodzi mi o to, zeby modul "raporty" przejal czesc logiki biznesowej, ktora powinna byc zawarta w module "magazyn" - bo tak to chyba zrozumiales, o ile ja poprawnie zrozumialem Twoja wypowiedz.
Modul magazym moze dostarczac stan magazynowy modulowi raporty, ale ten stan magazynowy czasem moze byc po prostu lista encji. Przykladowo modul magazym moze zawierac schedulera ktory na podstawie swojej wewnetrznej logiki wyznacza stan magazynowy i dodaje raz dziennie wpis do bazy danych, ktory ten stan zawiera. Jak modul raportow poprosi o historie stanow magazynu to dostanie nic innego jak wlasnie liste encji zawierajaca stan na kazdy dzien. Tutaj klasa encji bylaby przydatna w module raporty.
Tak czy inaczej to temat sie troche zagmatwal i chyba przyczyna takiego zagmatwania jest brak dobrego przykladu z mojej strony co prowadzi to do pewnych nieporozumien. Z drugiej strony na chwile obecna ciezko mi wymyslec na tyle dobry przyklad aby tych nieporozumien nie bylo - moze sie troche pospieszylem zakladajac ten watek.
Generalnie mowiac zaczelo sie od tego, ze w mojej glowie pojawila sie mysl, ze baza danych zawiera pewne tabele. Chcialbym te tabele budowac automatycznie na podstawie encji. Pomyslalem, ze relacje miedzy encjami moga wymusic na mnie pewna cykliczna zaleznosc modulow, ale jak staram sie wymyslec jakis przyklad to dochodze do wniosku, ze musialbym wymyslec przyklad zlego podzialu po to zeby pokazac o co mi chodzi. W momencie kiedy wymysle jakis poprawny podzial to akurat rozwiazuje sie problem cyklicznych zaleznosci :) Nie byloby w ogole problemu gdyby nie to, ze czuje, ze istnieje scenariusz z dobrym podzialem i problemem z cyklami :)
Ale tak z ciekawosci to jak rozwiazac taki problem? Zalozmy ze mam dwa moduly:
- modul uzytkownicy (zawiera encje User oraz roznego rodzaju uslugi na uzytkownikach, o ktorych nie ma sensu wspominac na razie).
- modul dokumenty (zawiera m.in. encje Document).
Encja User wygladalaby np. tak (odpuscilem sobie gettery, settery, adnotacje itd):
Kopiuj
class User
{
private String name;
private String password;
}
Encja Document wygladalaby np. tak:
Kopiuj
class Document
{
private User owner;
private String title;
private String content;
}
Teraz co by bylo gdybym z poziomu encji User chcial miec dostep do listy dokumentow użytkownika? Mozna byloby zrobic to tak:
Kopiuj
class User
{
private String name;
private String password;
private List<Document> documents;
}
Ale Maven mi na to nie pozwoli, poniewaz kazda z encji jest w oddzielnym module. Tutaj nie jest to jakis wielki problem poniewaz mozna sie bez pola documents obejsc i tabele w bazie danych zbuduja mi sie poprawnie. Problem bylby natomiast wtedy kiedy wstawilbym dowolna encje w module uzytkownicy, ktora:
- bylaby powiazana z encja z modulu documents
- przechowywalaby klucz obcy do encji z modulu documents
No i chcialem wlasnie zapytac jak tego typu problemy obchodzic. W pierwszej kolejnosci wpadlem na pomysl aby stworzyc modul z samymi encjami i ewentualnie repozytoriami, ale srednio mi sie to podobalo. Shalom zaproponowal podzial na moduly ze wzgledu na warstwy co tez rozwiazuje problem ale bede musial sie zastanowic czy taki podzial bylby rzeczywiscie najlepszym rozwiazaniem, bo wydaje mi sie ze ma pewne wady ale najpierw chcialbym sie upewnic czy dobrze go rozumiem :)
Maven 
