Aktywne Wpisy

Aż nie wiem jak to otagować. Linkedin właśnie wszedł na nowy, absurdalny poziom
#linkedin #patologiazmiasta #heheszki #korposwiat
#linkedin #patologiazmiasta #heheszki #korposwiat
źródło: obraz_2025-12-16_114445852
Pobierz
kukold +33
15 lat doświadczenia w IT. Java, React, SQL, Kubernetes, cloud infrastructure, cyber security. Systemy o dużej skali, odpowiedzialność za krytyczne komponenty, lata ciągłej nauki i pracy.
I dziś, z pełną świadomością, mogę powiedzieć jedno: to był błąd życiowy.
Programowanie w 2025 roku nie jest zawodem. Jest zajęciem technicznym bez statusu, bez prestiżu i bez jakiegokolwiek realnego umocowania społecznego. Nieważne, ile lat w tym siedzisz, ile technologii znasz, ile systemów postawiłeś od zera. Dla świata
I dziś, z pełną świadomością, mogę powiedzieć jedno: to był błąd życiowy.
Programowanie w 2025 roku nie jest zawodem. Jest zajęciem technicznym bez statusu, bez prestiżu i bez jakiegokolwiek realnego umocowania społecznego. Nieważne, ile lat w tym siedzisz, ile technologii znasz, ile systemów postawiłeś od zera. Dla świata





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ś?
źródło: l7knijwaobb51
Pobierz@aczutuse: ( ͡° ʖ̯ ͡°) ale zaśmierdziało legacy
źródło: giphy
Pobierzźródło: 1*aD3zDFzcF5Y2_27dvU213Q
Pobierz@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ą
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 ( ͡° ͜ʖ ͡°)
@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
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
domain/
----/entity
Komentarz usunięty przez autora