#ddd #oop #java #programowanie #hexagonalnaarchitektura
Jak mam se domenę, obiekty o znaczeniu biznesowym, które coś se robią, bez używania zewnętrznych rzeczy i mam adaptery, które potrafią np. przekonwertować obiekt domenowy do xml albo na dto albo wyciągnąć obiekt domenowy z bazy to teraz jak to połączyć? Prawidłowe będzie gdy:
stworzę se service, który będzie używał obiektów domenowych i adapterów (zdefiniowanych jako abstrakcji)?
Gdzie umieścić taki serwis? W pakiecie domain czy adapters? A może osobno?
A może to obiekt domenowy powinien używać se adapterów przez abstrakcję, a nie że serwajs jakiś?
Jak mam se domenę, obiekty o znaczeniu biznesowym, które coś se robią, bez używania zewnętrznych rzeczy i mam adaptery, które potrafią np. przekonwertować obiekt domenowy do xml albo na dto albo wyciągnąć obiekt domenowy z bazy to teraz jak to połączyć? Prawidłowe będzie gdy:
stworzę se service, który będzie używał obiektów domenowych i adapterów (zdefiniowanych jako abstrakcji)?
Gdzie umieścić taki serwis? W pakiecie domain czy adapters? A może osobno?
A może to obiekt domenowy powinien używać se adapterów przez abstrakcję, a nie że serwajs jakiś?
- Najlepsze
- Wszystkie komentarze
@aczutuse: I to jest właśnie zarąbiste w tej architekturze, że samo serce aplikacji nie jest zaśmiecone szczegółami technicznymi integracji z innymi usługami. Polecam przy tym tak samo potraktować bazę danych - jako jedną z opcji integracji, do której wystawiamy adaptery - nieźle rozwiązuje to pokusę pomieszania klas encji z agregatem domeny.
A odpowiadając na pytanie - pakowałbym to do adapters, bo IMHO to adaptery mają wiedzieć
to szczegół implementacyjny/util więc poza domeną - po co domena ma wiedzieć cokolwiek o warstwie
Czemu serwajs jest w warstwie infrastruktury nie aplikacji? Zwykle serwisy aplikacyjne odpowiedzialne za wykonanie jakiegoś use case'a jak nazwa mówi siedzą w warstwie aplikacji, chyba że to jakiś inny serwis, nie wiem. Zwykle jest tak, że web controller woła serwis aplikacyjny albo handler jak używasz CQRS i ten serwis/handler zajmuje się orkiestracją obiektów domenowych. Czyli pobiera agregat z bazy danych wykonuje logikę, zapisuje stan agregatu za pomocą repozytorium i jak trzeba to
webma referencję doapplicationi jednoczesnieapplicationma referencję doweb.Jeśli serwis operuje na DTO i jednocześnie jest wywoływany w kontrolerze to DTO muszą siedzieć w
Co do osobnego pakietu to zależy od skali i struktury projektu. Ja preferuję mieć osobne pakiety. Czyli mam pakiet z adapterami do bazy danych, pakiet z adapterami
@aczutuse: ( ͡° ʖ̯ ͡°) ale zaśmierdziało legacy
Przykładowo jeśli twoja firma zajmuje się dostarczaniem rozwiązań do parsowania xml-i, json-ów, csv-ów itd to obiekty wykonujące taką logikę są w rozumieniu DDD dziedziną
exceptioni wyciagnac go na wierzch?@aczutuse: Dla mnie REST to zwykle też infrastruktura, więc może być w tym samym (⌐ ͡■ ͜ʖ ͡■)
A po co exceptionom jakieś wyjątkowe traktowanie skoro mogą pojawić się w tylko w infrastrukturze i tam będą przechwycone? Domain-driven, a nie stary-tutorial-z-pakietami-wg-rodzajów-obiektów-driven ( ͡° ͜ʖ ͡°)