Podział aplikacji napisanych na moduły

Witajcie,
Zastanawiam się nad najlepszym podziałem większej aplikacji na moduły mavenowe.
Lepiej dzielić ją po funkcjonalnościach (np. płatności, przesyłka itp) czy może lepiej po warstwach (np. web, core itp)?

Ja tam się nie znam, ale
wydzieliłabym moduł webowy, bo rozumiem, że będzie jakaś JEDNA aplikacja, do której użytkownik będzie się logował i tam klikał (no chyba że więcej?) i kilka modułów backendowych po obszarze, którego dotyczy (czyli te twoje przykładowe płatności, przesyłka), no i te obszary miały by wewnątrz jeszcze jakiś podział na moduł 1: z dao i moduł 2: z serwisami.
Aczkolwiek takie dzielenie po funkcjonalnościach to tylko przy większych aplikacjach.

Odpowiedź na pytanie jest tu (z linkami do kolejnych artykułów):
http://programmers.stackexchange.com/questions/258196/java-application-structure-horizontal-vs-vertical-split

Po polsku - w uproszczeniu: raczej dzielić domenowo.

Akurat ten podział który wymieniłeś nie ma za bardzo sensu. Tzn jedno nie wyklucza drugiego ;)
Podział logiki biznesowej lepiej zrobić domenowo, ale jednocześnie w projekcie i tak powstanie ci też zbiór klas związanych z logiką aplikacji a nie z logiką biznesową, czyli takie coś w stylu core / infrastructure / commons. Szczególnie jeśli masz tam np. jakieś webserwisy jeszcze czy coś w tym stylu, wtedy lepiej mieć te zalezności w jednym module a nie wrzucać ich do tych "domenowych".

Raz tylko popełniłem projekt gdzie wszystko było podzielone tylko domenowo (i w efekcie np. moduł odpowiedzialny za X miał oprócz klas domenowych także kontrolery i widok) ale to był bardzo szczególny przypadek, gdzie istniało wymaganie, że moduły są samowystarczalne i można każdy z nich deployować osobno, w efekcie takie rozwiązanie miało sens. Ale nie jestem pewien czy zwykle ma to sens. (no i tam i tak był moduł na commonsy)

Przykładowo - dzieli się też już ładnie Weba (nie trzeba mieć jednej aplikacji WEB... )

Można rozważyć taki podział na moduły, aby można było łatwo integracyjnie przetestować cały moduł: kierować się kryterium testowalności.

standard i klasyczna wersja mówi, że dzieli się na pakiety dao (albo repository), model(albo domain), service, business, controller itd..
Standard to standard - prawdopodobnie setki ludzi do tego dochodziło latami i po pewnym czasie wspólnie doszli do podobnych wniosków, że tak będzie najlepiej.
Potem będziesz chciał użyć sobie AOP do monitorowania wywołań jakiejś warstwy albo cuś i będzie płacz i zgrzytanie zębów. Oczywiście mowie o zwykłych aplikacjach dużych monolitycznych.