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ś?
@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ć
@aczutuse: Odpowiedź jest prosta. Czy jest to część twojej domeny biznesowej to znaczy czy jest czymś unikalnym i stanowi o wartości/przewadze biznesową nad konkurencją, czy jest zwykłym szczegółem technicznym/implementacyjnym? Jeśli to pierwsze to powinno być częścią domeny. Jeśli to drugie to powinno być częścią warstwy infrastruktury.
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ą
@PaaD: a mapper, który mapuje obiekt domenowy na dto? W pakiecie web gdzie jest RestController? Czy do adapterów? A może do domeny, bo to trochę logika biznesowa pt. "jak prezentować nasz obiekt"?
@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 ( ͡°͜ʖ͡°)
a mapper, który mapuje obiekt domenowy na dto? W pakiecie web gdzie jest RestController? Czy do adapterów? A może do domeny, bo to trochę logika biznesowa pt. "jak prezentować nasz obiekt"?
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 publikuje event domenowy żeby powiadomić inne konteksty o zdarzeniu.
@aczutuse: Jeśli w twoim przypadku umieścisz DTO w web, który jest częścią infrastruktury, to w jaki sposób serwis aplikacyjny który nie powinien mieć referencji do komponentów będących częścią warstwy infrastruktury będzie na nich operował? Nie możesz mieć sytuacji w której pakiet web ma referencję do application i jednoczesnie application ma referencję do web.
Jeśli serwis operuje na DTO i jednocześnie jest wywoływany w kontrolerze to DTO muszą siedzieć w
@markaron: ma to szysku se sens, mądrości. Tyku jedna rzecz mnie martwi, że jak mam se teraz główną encję Document i dodam se nową encję np. Payment to bedem miał podzielone te pakiety nie wg domeny tyku wg ich typu:
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ś?
@aczutuse: ( ͡° ʖ̯ ͡°) ale zaśmierdziało legacy
@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ć
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ą
exception
i 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 ( ͡° ͜ʖ ͡°)
@PaaD: bedom wywalone do logów i w odpowiedzi restowej (w odpowiedzi opakowywane są w kod błędu jeszcze)...
Dałem se to do application/web.
/application
----/exception
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 publikuje event domenowy żeby powiadomić inne konteksty o zdarzeniu.
Ja bym widział coś takiego
/application
web
ma referencję doapplication
i jednoczesnieapplication
ma referencję doweb
.Jeśli serwis operuje na DTO i jednocześnie jest wywoływany w kontrolerze to DTO muszą siedzieć w
domain/
----/entity
Komentarz usunięty przez autora