Modularyzacja aplikacji z użyciem modułów gradle

Hej,

zaczynając refactor aplikacji zacząłem zastanawiać się nad wydzieleniem odpowiednich modułów gradle. Mam kilka bounded contextów, warstwę infrastruktury, aplikacji. Widziałem prosty podział na "domain", "infrastructure", "application", ale nie do końca mnie to przekonuje. Chciałbym chyba rozdzielić też konteksty i nie traktować całej domeny jako jedno. Macie jakieś fajne przykłady/artykuły na ten temat?

Myślałem np. o module gradle per kontekst, a w nim podział pakietowy application/domain/infrastructure. Zastanawiam się co natomiast co jeśli oba moduły wymagają tej samej infrastruktury - wtedy powinienem wydzielić jej część do wspólnego modułu?

W skrócie - szukam przykładów i inspiracji :)

A czemu nie podzielić domeny na osobne moduły, jeśli uważasz ze jest taka potrzeba, a infrastrukturę (które przecież i tak będzie bardzo mała, pewnie raptem kilka kontrolerów, konfiguracja security itd) zostawić w jednym module?

@Shalom: Mam tutaj podobny problem. W swojej aplikacji też w portach/adapterach mam taki sam podział:

• application: incoming adapters czyli np. web typu kontrolery
• domain: tu wiadomo
• infrastructure: konfiguracja i repozytorium itp

Jak myślisz, nie lepiej byłoby złączyć razem application i infrastructure w samo tylko infrastructure, i tam miałbym, zarówno adaptery wchodzące i wychodzące razem bo i tak domena jest odseparowana, a właściwie to jest głównym zadaniem Ports/Adapters?
Przez to, że mam własnie application i infrastructure osobno, mam również problem z cyklami pomiędzy modułami a łamie mi to zasadę ADP w Component Coupling, bo mam moduł z klasami, które są używane w testach integracyjnych (podobnie jak u Ciebie w projekcie z S3 :D), i przez to, że używam Spocka, muszę zaimportować do bazowej klasy testów integracyjnego główną klasę Main i jest z tym problem własnie poprzez cykl.

@stvtro a czym w takim razie jest u ciebie application a czym infrastructure? Jeśli miałbym zrobić taki podział z jakiegoś powodu, to wyciągnąłbym w zasadzie tylko main i application configuration do osobnego modułu, a kontrolery itd miał w osobnym module, tylko nie widzę specjalnie sensu w takim podziale.

@Shalom: Wygląda to tak:
application: tutaj mam adaptery wchodzące czyli kontrolery
infrastructure: tu mam konfigurację i repozytorium razem w pakietach config i repository. W repository jest zwyczajna implementacja komunikacja z Postgresem przez JooQ, którego używam :D

Klasę odpalającą z metodą main() mam własnie w osobnym module server, ale że właśnie moduł test potrzebuje tej klasy w adnotacji @SpringBootTest, która jest na głównej klasie do testów integracyjnych IntegrationSpec, to importuję w module test modul serwer, i przez to mam cykl, bo z kolei moduł application dodaje jako dependency moduł test, bo mam tam testy integracyjne kontrolerów więc potrzebuję klasy IntegrationSpec, od której dziedziczy mój kontroler np. jakiś UserControllerSpec extends IntegrationSpec.

Co sądzisz o takim podziale w takim razie:

• config: tu będzie konfiguracja aplikacji, tworzenie fasady i innych beanów itp
• infrastructure: tu polecą razem kontrolery i repository jako osobne pakiety, ogólnie incoming/outgoing adapters
• main/server: tu będzie tylko klasa z metodą main i cokolwiek z tym związane
• test: tutaj wspólne klasy dla testów integracyjnych itp

Czy moze konfiguracja aplikacji powinna być razem z server zwyczajnie w pakiecie config? Miałbym tam inicjalizację Fasady, wszystkich beanów itp razem z metodą main jako jeden moduł?

moduł application dodaje jako dependency moduł test

Tego nie rozumiem. Testy to testy i nie powinny od nich zależeć żadne aplikacyjne moduły. Jeśli masz taką potrzebę to zrób jeszcze jeden moduł na jakieś commons które są potrzebne i w application i w test.

Tego właśnie potrzebowałem, bo już kompletnie pogubiłem się, mimo że sobie cały graf tych zależności rozrysowałem. Dzięki! :D