Mam pytanie o Clean Architecture. W który obszarze należy umieścić logikę, której głównym zadaniem jest wysyłanie danych do zewnętrzengo API a nie pobieranie?
Aha, czyli według Ciebie Data Layer z założenia ma działać odbiorczo-nadawaczo? Mój konkretny przypadek z aplikacji, to wysyłanie statystyk użycia apki na zew. serwer.
I jeszcze jedno. Czy wysyłka statystyk użycia apki to jest "use case" domeny? Czy use case to jest tylko to co jawnie robi user?
@czlowiek_z_lisciem_na_glowie: masz nieprecyzyjne pytanie dlatego masz 3 różne odp. z czego w sumie każda jest prawdziwa. Bo musisz określić co to jest logika wysyłania a nie pobierania?
@czlowiek_z_lisciem_na_glowie: Można tak powiedzieć, nie widzę żadnej różnicy miedzy odczytem/zapisem z bazy a z rest api. Na diagramie który wrzuciłeś brakuje warstwy frameworków. Użycie gataway umożliwia ci rozdzielenie kodu użycia konkretnego frameworka od usecase wysyłania statystyk. Dzięki temu możesz np zmienić operatora statystk implementując nowego gataway i nie ruszajac reszty aplikacji. Rozwijając twój konkretny przypadek załóżmy, że masz przycisk zamknij. UI przekazuje naciśniecie przycisku do Controllera. Controller wywołuje 2 przypadki
Dzięki. Mógłbyś mi jeszcze napisać - co jeśli obiekt statystyki jest troszkę bardziej złożony niż "close". Gdzie mapuję informacje na obiekt DTO, który zasili Gateway - po stronie domeny, czy po stronie data Layer? W którym obszarze ma zostać utworzona fizyczna instancja obiektu DTO niosącego payload statystyki. Innymi słowy, czy fabryka DTO może istnieć w domenie czy domena ma przekazać informacje do wygenerowania DTO do Data?
@czlowiek_z_lisciem_na_glowie: Wysyłanie i odbieranie danych to adapter i nie powinno tam być biznesowej logiki tylko taka, która przygotowuje odpowiedź zgodną z kontraktem i rzuca wyjątki jeśli serwis niedostępny albo niespodziewany format odpowiedzi. Tak jak w widokach, możliwa jest logika typu: "Jeśli wartość pola w DTO jest taka to daj czerwony kolor". Chodzi o to, żeby integracyjnie testować sam kontrakt, a logikę tego co robisz z odpowiedziami przetestujesz jednostkowo z podpiętymi
#androiddev #kotlin #programowanie
źródło: comment_16630668599CcxnNcPgZ9eT7AOY6myYt.jpg
PobierzKomentarz usunięty przez autora
Aha, czyli według Ciebie Data Layer z założenia ma działać odbiorczo-nadawaczo?
Mój konkretny przypadek z aplikacji, to wysyłanie statystyk użycia apki na zew. serwer.
I jeszcze jedno. Czy wysyłka statystyk użycia apki to jest "use case" domeny? Czy use case to jest tylko to co jawnie robi user?
Na diagramie który wrzuciłeś brakuje warstwy frameworków. Użycie gataway umożliwia ci rozdzielenie kodu użycia konkretnego frameworka od usecase wysyłania statystyk. Dzięki temu możesz np zmienić operatora statystk implementując nowego gataway i nie ruszajac reszty aplikacji.
Rozwijając twój konkretny przypadek załóżmy, że masz przycisk zamknij. UI przekazuje naciśniecie przycisku do Controllera. Controller wywołuje 2 przypadki
Dzięki. Mógłbyś mi jeszcze napisać - co jeśli obiekt statystyki jest troszkę bardziej złożony niż "close". Gdzie mapuję informacje na obiekt DTO, który zasili Gateway - po stronie domeny, czy po stronie data Layer? W którym obszarze ma zostać utworzona fizyczna instancja obiektu DTO niosącego payload statystyki. Innymi słowy, czy fabryka DTO może istnieć w domenie czy domena ma przekazać informacje do wygenerowania DTO do Data?