Architettura pulita: troppe classi di casi d'uso

Vado in Clean Architecture e alzo il mio livello Android da MVC a MVP , introducendo DI con Dagger 2, Reactivity con RxJava 2 e, naturalmente, Java 8.

Nell'architettura pulita MVP è presente un livello tra le entità (nei datastore) e i presentatori che dovrebbero accedervi. Questo livello è il "Caso d'uso" . Un caso d'uso è idealmente un'interfaccia, che implementa UNA operazione su UNA entità.

So anche che Clear Architecture " sta urlando ", in quanto i suoi progetti sono davvero altamente leggibili come l'alto numero di classi in essi.

Ora, nel mio progetto, ho qualcosa come 6 entità diverse e, naturalmente, ogni repository di entità ha almeno 4 metodi (di solito ottieni, aggiungi, elimina, aggiorna) per accedervi .. quindi, 6 * 4 = 24 .

Se quello che ho capito finora di Clean Architecture, avrò 24 UseCase.

Si tratta di molte classi se confrontate con solo 6 controller in MVC.

Devo davvero fare 24 casi d'uso?

Apprezzerò davvero un chiarimento da parte di qualcuno che lo ha già utilizzato con successo.

Grazie Jack

— Jackie Degl'Innocenti
fonte

Puoi pubblicare un link a una pagina che descrive in dettaglio questi casi d'uso, con un codice di esempio?

— Robert Harvey,

Ho cercato su Google molto, ma principalmente: questo esempio di app e l'articolo correlato: github.com/jshvarts/OfflineSampleApp ; questo articolo: proandroiddev.com/… ; proandroiddev.com/… ; Questo discorso: youtube.com/watch?v=TvsOsgd0--c&feature=youtu.be ; E anche questo articolo: adityaladwa.wordpress.com/2016/10/25/…

— Jackie Degl'Innocenti

Nessuna delle app o degli articoli di esempio citati sembra avere molto a che fare con Clean Architecture. Parlano molto della programmazione reattiva.

— Robert Harvey,

L'app di esempio è sicuramente realizzata con il paradigma di Clean Architecture .. Gli altri articoli principalmente .. Cosa vuoi vedere @RobertHarvey?

— Jackie Degl'Innocenti,

Leggi la mia risposta qui sotto e rispondi.

— Robert Harvey,

Risposte:

Devo davvero fare 24 casi d'uso?

Solo se tutto ciò che scrivi è CRUD .

Fare riferimento allo schema seguente:

La tua affermazione è che avrai sei entità diverse e 4 metodi (Crea, Leggi, Aggiorna ed Elimina) per ogni entità. Ma questo è vero solo nel cerchio giallo al centro del diagramma (il livello Entità). È inutile creare 24 metodi nel livello Use Cases che passano semplicemente attraverso le chiamate CRUD al livello Entities.

Un caso d'uso non è "Aggiungi un record cliente". Un caso d'uso è più simile a "Vendi un articolo a un cliente" (che coinvolge entità cliente, prodotto e inventario) o "Stampa una fattura" (che coinvolge le stesse entità, oltre all'intestazione fattura e agli elementi pubblicitari fattura ).

Quando crei casi d'uso, dovresti pensare alle transazioni commerciali, non ai metodi CRUD.

Ulteriore lettura
aggregata: un cluster di oggetti di dominio che possono essere trattati come una singola unità

— Robert Harvey
fonte

Stai spendendo troppo tempo a pensare a modelli, pratiche e architettura e non abbastanza a pensare alla progettazione di software di base. Tutto ciò che serve sono i metodi che incarnano le pratiche commerciali, come ho descritto nella mia risposta.

— Robert Harvey,

Non si tratta di scegliere un'architettura. La mia opinione personale: le operazioni CRUD nude dovrebbero parlare direttamente con l'Entity Layer. Naturalmente, questo probabilmente viola l'architettura pulita.

— Robert Harvey,

Ti manca un po 'il punto. L'architettura è solo un mezzo per organizzare il codice. Risolvi i problemi scrivendo codice, non lottando con le architetture.

— Robert Harvey,

Ehi Robert, non è così carino che pensi che non scriva codice. L'argomento della mia risposta è sull'architettura e non siamo su SO. Sinceramente trovo i tuoi ultimi commenti davvero fuorvianti e sordi. La domanda riguarda UseCase in Clean Arch., Non la scrittura di codice. Se stai cercando di comunicare qualcosa, ti preghiamo di spiegare meglio, perché mi manca il punto dei tuoi commenti. IMHO non è possibile evitare la considerazione dell'architettura durante lo sviluppo di software, o almeno, i buoni sviluppatori non scrivono solo un sacco di codice. Inoltre ho fatto una domanda davvero specifica nel mio commento, puoi rispondere? Grazie

— Jackie Degl'Innocenti l'

La soluzione al problema che hai posto (prima l'app offline) non ha molto a che fare con Clean Architecture. Non troverai una soluzione a questo problema nel diagramma di Clean Architecture.

— Robert Harvey,

Hai ragione se ogni operazione CRUD è tradotta in una UseCase. Ma un UseCase può anche consistere in più operazioni CRUD.

Un UseCase è un modello separato che raccoglie informazioni da diverse origini dati e prepara la comunicazione con i data sink. Possono essere coinvolte più operazioni CRUD.

Pensa quindi a un UseCase in cui creare una fattura per un cliente E creare anche il cliente stesso perché non esiste nel sistema. Hai un UseCase che risulta in almeno due operazioni di creazione in una transazione.

— oopexpert
fonte

Quindi quale schema consiglieresti per l'esempio del CRUD con molte entità?

— Jackie Degl'Innocenti il

La mia opinione personale su questo è: non ho problemi ad avere molte classi purché non violino SRP (principio di responsabilità singola). Ma il più delle volte ridefinirei le Usecase "crea un'entità", "aggiorna un'entità", "elimina un'entità" e "aggiorna un'entità" a una semplice "entità di tipo X". Spesso si fornisce un'unica interfaccia utente per gestire un'entità. Questo è esattamente ciò che dovrebbe essere utilizzato da UseCase: il modo di gestire un carico di lavoro vantaggioso per la tua azienda.

— oopexpert,

Ok, quindi, avere un caso d'uso che gestisce varie operazioni diverse non sembra violare SRP in quanto sembra semplicemente "aggregare" metodi (e flussi) più diversi nello stesso UseCase senza che un singolo flusso gestisca più di una responsabilità. .. ma in questo modo non stiamo semplicemente creando un controller al posto di un UseCase? .. idea .. Forse il caso d'uso deve essere semplicemente visto come un livello, e quel livello deve solo rispettare SRP ma può anche implementare molti metodi. Vorrei avere una fonte o un articolo a riguardo

— Jackie Degl'Innocenti il

Un Usecase È un controller. L'unica differenza è che un caso d'uso viene dal punto di vista aziendale e un controller è la visione tecnica su di esso. Il focus di un caso d'uso è ciò che sta generando il valore aziendale. Quindi un caso d'uso è un'implementazione del controller basata sul valore aziendale.

— oopexpert,

D'accordo, un controller HTTP è un modo di gestire l'I / O, ci possono anche essere comandi della console, reazioni agli eventi e così via. Tutti questi canali I / O chiamano lo stesso caso d'uso. Un caso d'uso È un controller per la logica aziendale, non conosce i canali I / O da cui è stato chiamato, ma sa come orchestrare entità di dominio per svolgere il lavoro.

— Dmitriy Lezhnev

La tua definizione di Use Case è errata, Use Case è una classe che implementa una regola aziendale, non deve essere un'operazione CRUD, può essere un'operazione multi-step complessa

— Buckstabue
fonte

La tua frase non significa una soluzione quando hai effettivamente bisogno di implementare una vasta gamma di operazioni simili a Crud, anche la tua considerazione potrebbe trovare una relazione con il fatto che un caso d'uso dovrebbe osservare un modello in cui potremmo accedere a un'operazione complessa, anche multi-step.

— Jackie Degl'Innocenti