[a.....e]

#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ś?

[markaron]

@aczutuse: Tu już poruszasz inne zagadnienie - struktury pakietów w aplikacji. Są różne szkoły i opinie. Dużo zależy od skali aplikacji. Jak masz relatywnie prostą domenę, to taki podział jaki pokazałeś gdzie obiekty domenowe siedzą w jednym pakiecie ma sens.

W przypadku gdy robisz coś bardziej złożonego jak modularny monolit i masz kilka bounded contextów i subdomen w jednej aplikacji to wtedy podział po subdomenach/kontekstach ma więcej sensu. I wtedy

[a.....e]

@markaron: no, bo przy takim podziale chyba szyskie klasy publiczne muszom być a można by tak pogrupować by były package scope i tylko serwis public i agregat ewentualnie

[a.....e]

@markaron: koliego, a czu jak mam se 2 domeny czyli 2 takie kółka hexagonalne i one ciom se ze sobą gadać? Czy jedna warstwa aplikacji może se gadać z drugą wartswą aplikacji?

[markaron]

@aczutuse:

no, bo przy takim podziale chyba szyskie klasy publiczne muszom być a można by tak pogrupować by były package scope i tylko serwis public i agregat ewentualnie

tak, przy package by feature można zastosować package scope. Przy package by layer to klasy muszą być publiczne. Można też połączyć jedno i drugie. Ale to wymaga już głębszej analizy, planowania

[a.....e]

@markaron: huhu

[a.....e]

@markaron: tyko nie każ mi w 1 mikroserwisie wysyłać zdarzenie do Kafki z domeny Payment, które odbierze ten sam mikroserwis z domeny Document xD

springowe eventy są fajne, można w runtime zrobić se

[markaron]

springowe eventy są fajne, można w runtime zrobić se

@aczutuse: No można, wszystko zależy od wymagań. Jeśli logika biznesowa pozwala na gwarancję dostarczenia wiadomości w modelu at-most-once to takie zdarzenia in memory są ok. Jeżeli okazałoby się że wymagane jest at-least-once delivery to trzeba się posiłkować jakimś data store i wzorcem Outbox Pattern, żeby mieć pewność że zdarzenie nie zginęło "po drodze"

[a.....e]

@markaron: czu a to nawet nie wiedzialem se, ze te springowe sa at-most-once hms

[markaron]

czu a to nawet nie wiedzialem se, ze te springowe sa at-most-once hms

@aczutuse: nie znam Springa więc mogę być w błędzie niemniej trzeba zrobić sobie mały eksperyment myślowy. Co się stanie jeśli stan agregatu A zostanie zapisany w reakcji na co zostanie wyemitowany event E i w trakcie obsługi zdarzenia E przez handler EH kontener aplikacji stwierdzi że to najwyższa pora na restart. Czy po restarcie Spring jest w

[a.....e]

@markaron: pewnie nie, hms

[a.....e]

@markaron: a dzie dać se Klasę Job czyli która ma zdefiniowany jakieś działanie i odpala się np. co godzinę?
w app czy infra?
a może mogę dać do osobnego pakietu job?

[markaron]

@aczutuse: Infra bo to jest szczegół implementacyjny. Dziś używasz wbudowanych Springowych komponentów, a jutro możesz chcieć użyć dedykowanej zewnętrznej biblioteki, a po jutrze będziesz chciał odpalać job-a poza procesem aplikacji żeby mieć pewność, że jak padnie aplikacja to job będzie sobie dalej działał.

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