Czysta architektura - zbyt wiele klas przypadków użycia

Wchodzę w czystą architekturę i podnoszę poziom Androida z MVC do MVP , wprowadzając DI z Dagger 2, Reactivity z RxJava 2 i oczywiście Java 8.

W czystej architekturze MVP istnieje warstwa między jednostkami (w magazynach danych) a prezenterami, które powinny mieć do nich dostęp. Ta warstwa to „Przypadek użycia” . Przypadek użycia to idealnie interfejs, który implementuje JEDNĄ operację na JEDNEJ jednostce.

Wiem też, że Clear Architecture „ krzyczy ”, ponieważ jego projekty są naprawdę bardzo czytelne, ponieważ zawiera w nich dużą liczbę klas.

Teraz w moim projekcie mam około 6 różnych encji i oczywiście każde repozytorium encji ma co najmniej 4 metody (zazwyczaj pobierz, dodaj, usuń, zaktualizuj), aby uzyskać do nich dostęp. Więc 6 * 4 = 24 .

Jeśli to, co do tej pory rozumiałem z Clean Architecture, będę miał 24 UseCase.

Jest to dużo klas w porównaniu do zaledwie 6 kontrolerów w MVC ..

Czy naprawdę muszę wykonać 24 przypadki użycia?

Naprawdę docenię wyjaśnienie, które ktoś z powodzeniem wykorzystał.

Dzięki, Jack

— Jackie Degl'Innocenti
źródło

Czy możesz zamieścić link do strony opisującej szczegółowo te przypadki użycia, na przykład kod?

— Robert Harvey

Często googlowałem , ale głównie: ta próbka aplikacji i powiązany artykuł: github.com/jshvarts/OfflineSampleApp ; te artykuły: proandroiddev.com/… ; proandroiddev.com/… ; Ta rozmowa: youtube.com/watch?v=TvsOsgd0--c&feature=youtu.be ; A także te artykuły: adityaladwa.wordpress.com/2016/10/25/…

— Jackie Degl'Innocenti

Żadna z cytowanych przez Ciebie przykładowych aplikacji lub artykułów nie ma wiele wspólnego z czystą architekturą. Mówią jednak dużo o programowaniu reaktywnym.

— Robert Harvey

Przykładowa aplikacja jest z pewnością wykonana według paradygmatu Clean Architecture. Pozostałe artykuły głównie… Co chcesz zobaczyć na @RobertHarvey?

— Jackie Degl'Innocenti

Przeczytaj moją odpowiedź poniżej i odpowiedz.

— Robert Harvey,

Odpowiedzi:

Czy naprawdę muszę wykonać 24 przypadki użycia?

Tylko jeśli wszystko, co piszesz, to CRUD .

Zobacz poniższy schemat:

Zapewniasz, że będziesz mieć sześć różnych encji i 4 metody (Utwórz, Odczytaj, Aktualizuj i Usuń) dla każdej encji. Ale dotyczy to tylko żółtego koła na środku diagramu (warstwa Istot). Nie ma sensu tworzyć 24 metod w warstwie Use Cases, które jedynie przechodzą przez wywołania CRUD do warstwy Entities.

Przypadkiem użycia nie jest „Dodaj rekord klienta”. Przypadek użycia jest bardziej podobny do „Sprzedaj przedmiot klientowi” (który obejmuje podmioty klienta, produktu i zapasów) lub „Wydrukuj fakturę” (który obejmuje te same podmioty, oprócz nagłówka faktury i pozycji wiersza faktury ).

Tworząc przypadki użycia, powinieneś myśleć o transakcjach biznesowych, a nie o metodach CRUD.

Dalsza lektura
Agregat - klaster obiektów domenowych, które można traktować jako pojedynczą jednostkę

— Robert Harvey
źródło

Spędzasz zbyt dużo czasu na myśleniu o wzorcach, praktykach i architekturze, a za mało czasu na myślenie o podstawowym projektowaniu oprogramowania. Wszystko czego potrzebujesz to metody ucieleśniające praktyki biznesowe, jak opisałem w mojej odpowiedzi.

— Robert Harvey,

To nie jest kwestia wyboru architektury. Moja osobista opinia: nagie operacje CRUD powinny rozmawiać bezpośrednio z warstwą jednostki. Oczywiście prawdopodobnie narusza to czystą architekturę.

— Robert Harvey,

Trochę brakuje ci sensu. Architektura jest tylko środkiem do porządkowania kodu. Rozwiązujesz problemy pisząc kod, nie walcząc z architekturą.

— Robert Harvey,

Hej Robert, to nie jest tak miłe, że zakładasz, że nie piszę kodu. Temat mojej odpowiedzi dotyczy architektury, a my nie zajmujemy się SO. Z poważaniem uważam, że twoje ostatnie komentarze są bardzo mylące i głuche. Pytanie dotyczy UseCase w Clean Arch., A nie pisania kodu. Jeśli próbujesz coś przekazać, wyjaśnij to lepiej, ponieważ brakuje mi sensu twoich komentarzy. IMHO nie można uniknąć rozważania architektury podczas tworzenia oprogramowania, a przynajmniej dobrzy deweloperzy nie tylko piszą mnóstwo kodu. Ponadto w moim komentarzu zadałem naprawdę konkretne pytanie, czy potrafisz odpowiedzieć? Dzięki

— Jackie Degl'Innocenti,

Rozwiązanie postawionego problemu (najpierw aplikacja offline) tak naprawdę nie ma wiele wspólnego z czystą architekturą. Nie znajdziesz rozwiązania tego problemu na schemacie czystej architektury.

— Robert Harvey,

Masz rację, jeśli każda operacja CRUD została przetłumaczona na jeden przypadek użycia. Ale UseCase może również składać się z wielu operacji CRUD.

UseCase to oddzielny model gromadzący informacje z różnych źródeł danych i przygotowujący komunikację do ujść danych. Może być zaangażowanych wiele operacji CRUD.

Pomyśl więc o UseCase, w którym tworzenie faktury dla klienta ORAZ tworzenie samego klienta, ponieważ on / ona nie istnieje w systemie. Masz jeden UseCase, który powoduje co najmniej dwie operacje Create-Operations w jednej transakcji.

— oopexpert
źródło

Więc jaki wzorzec poleciłbyś na przykład CRUD dla wielu podmiotów?

— Jackie Degl'Innocenti,

Moje osobiste zdanie na ten temat jest następujące: nie mam problemu z prowadzeniem wielu zajęć, o ile nie naruszają SRP (zasada pojedynczej odpowiedzialności). Ale ja przez większość czasu redefiniuję przypadki użycia: „Utwórz encję”, „Zaktualizuj encję”, „Usuń encję” i „Zaktualizuj encję” na proste „Zarządzaj encją typu X”. Często udostępniasz pojedynczy interfejs użytkownika do zarządzania jednym podmiotem. Ale dokładnie to powinien zdefiniować Twój UseCase: sposób obsługi korzystnego obciążenia pracy dla Twojej firmy.

— oopexpert,

Ok, więc posiadanie przypadku użycia, który zarządza różnymi operacjami, nie narusza SRP, ponieważ wydaje się, że po prostu „agreguje” więcej różnych metod (i przepływów) w tej samej UseCase bez tego, że jakikolwiek pojedynczy przepływ obsługuje więcej niż jedną odpowiedzialność. .. ale czy w ten sposób nie tworzymy tylko kontrolera zamiast UseCase? .. pomysł .. Może przypadek użycia musi być po prostu postrzegany jako warstwa, a ta warstwa musi po prostu przestrzegać SRP, ale może także implementować wiele metod. Chciałbym mieć źródło lub artykuł na ten temat

— Jackie Degl'Innocenti,

Przypadek użycia jest kontrolerem. Jedyną różnicą jest to, że przypadek użycia pochodzi z perspektywy biznesowej, a kontroler jest z technicznego punktu widzenia. Przykładem zastosowania jest generowanie wartości biznesowej. Tak więc przypadek użycia jest implementacją kontrolera opartego na wartości biznesowej.

— oopexpert,

Zgadzam się, kontroler HTTP to sposób zarządzania we / wy, mogą być również komendy konsoli, reakcje na zdarzenia i tak dalej. Wszystkie te kanały We / Wy nazywają tę samą przypadek użycia. Przypadek użycia JEST kontrolerem logiki biznesowej, nie wie o kanałach We / Wy, z których został wywołany, ale wie, jak zaaranżować jednostki domeny w celu wykonania zadania.

— Dmitriy Lezhnev,

Twoja definicja przypadku użycia jest niepoprawna, przypadek użycia to klasa implementująca regułę biznesową, nie musi to być operacja CRUD, może być złożoną operacją wieloetapową

— Buckstabue
źródło

Twoje zdanie nie oznacza rozwiązania, kiedy faktycznie potrzebujesz wdrożyć szeroki zakres operacji podobnych do Crud, nawet twoje rozważanie może znaleźć pewien związek z faktem, że Przypadek użycia powinien przestrzegać wzoru, w którym moglibyśmy uzyskać dostęp do złożonej operacji, nawet wieloetapowy.

— Jackie Degl'Innocenti