Próbuję aktualnie połączyć wiedzę w praktyce, którą zdobyłem z książki Clean Architecture, z różnych artykułów o Hexagonal Architecture/Ports Adapters oraz o stosowaniu podejścia package-scope/published, które przedstawił Kuba Nabradalik w swojej prezentacji:
Kod znajduje się tu: https://github.com/jakubnabrdalik/hentai
Mam jednak kilka pytań, zwłaszcza, że widząc rózne przykłady w internecie, każdy podchodzi do tego inaczej.
- Jaka powinna być struktura i nazewnictwo pakietów, które przechowują adaptery wchodzące/wychodzące (incoming/outgoing adapters), domenę oraz porty?
Czy application/adapters na aprzechowywanie adapterów wchodzących, domain na domenę oraz infrastructure dla adapterów wychodzących to dobre podejście?
W jednym podejściu widziałem, że adaptery wchodzące są przechowywane a pakiecie application, natomiast wychodzące w pakiecie infrastructure:
└── com
└── github
└── shop
├── application
│ └── controller
│ └── OrderController.java
├── domain
│ ├── dto
│ ├── entity
│ ├── OrderFacade.java
│ └── ports
│ ├── incoming
│ └── outgoing
└── infrastructure
├── console
└── repository
Z kolei np w przykładzie Jakuba Nabradalika z linku, występuje tylko domain, w którym nawet nie ma pakietu ports, więc w pakiecie domain pomieszane ze sobą incoming/outgoing ports, a repozytoria np. OrderRepository, InMemoryOrderRespitory również są w pakiecie domain, ale nie są pogrupowane oraz infrastructure, natomiast brakuje adapters.
Które z podejść jest Waszym zdaniem najbardziej polecane i czy powinnśmy dzielić porty również na podpakiety incoming/outgoing?
-
Jaka powinna być rola Fasady? Czy fasada powinna tylko i wyłącznie komunikować się z incoming/outgoing adapters np. być wywoływana z kontrolera np. RestController, czy może również zawierać logikę biznesową, lub nie powinna i logika biznesowa lub najróżniejsze operacje Domeny powinny znajdować się w klasach np OrderService, które odpala Fasada lub tez w obiektach domenowych (Entity Object) w pakiecie domain?
-
Czy w przypadku zastosowania monolitu i obecności większej liczby komponentów, powinno się stosować package-by-feature, żeby odzielić od siebie rózne funkcjonalności biznesowe na przykładzie sklepu: komponents Complaints do reklamacji, Orders do zamówień, Shipping do wysyłek, Invoice do faktur:
└── com
└── github
└── shop
├── complaints
│ ├── application
│ │ └── controller
│ │ └── ComplaintsController.java
│ ├── domain
│ │ ├── ComplaintsFacade.java
│ │ ├── dto
│ │ ├── entity
│ │ └── ports
│ │ ├── incoming
│ │ └── outgoing
│ └── infrastructure
│ └── repository
├── invoice
│ ├── application
│ │ └── controller
│ │ └── InvoiceController.java
│ ├── domain
│ │ ├── dto
│ │ ├── entity
│ │ ├── InvoiceFacade.java
│ │ └── ports
│ │ ├── incoming
│ │ └── outgoing
│ └── infrastructure
│ └── repository
├── order
│ ├── application
│ │ └── controller
│ │ └── OrderController.java
│ ├── domain
│ │ ├── dto
│ │ ├── entity
│ │ ├── OrderFacade.java
│ │ └── ports
│ │ ├── incoming
│ │ └── outgoing
│ └── infrastructure
│ ├── console
│ └── repository
└── shipping
├── application
│ └── controller
│ └── ShippingController.java
├── domain
│ ├── dto
│ ├── entity
│ ├── ports
│ │ ├── incoming
│ │ └── outgoing
│ └── ShippingFacade.java
└── infrastructure
└── repository
- Czy taka struktura pakietów jak ma również sens w przypadku kiedy system jest podzielony ma serwisy/mikroserwisy, gdzie każdy mikroserwis jest w osobnym repozytorium. ma osobną bazę danych oraz ogólnie stanowi osobny Bounded Context/Subdomain w kontekście DDD, czy może zwykła tradycjny podział typu controller/service/domain spokojnie wystarczy, zwłaszcza kiedy mikroserwisy są osobnymi projektami i znajdują się w innych repozytoriach?
Z góry dzięki ;)