Architettura pulita - Come gestisco il riutilizzo del caso d'uso?

Question

Architettura pulita - Come gestisco il riutilizzo del caso d'uso?

#1 da (9 voti)

3

Cercando di applicare l'architettura pulita di Uncle Bob a un'applicazione che sto mantenendo e sto riscontrando difficoltà con casi d'uso e duplicazione / riutilizzo. È mia opinione che gli use case debbano essere autonomi e che ci si possa aspettare una duplicazione, ma questo non sembra avere senso con quello che sto trattando. Ritengo che ci siano più casi d'uso che dovrebbero finire con l'uso di altri casi d'uso.

Ecco un esempio molto semplice di 4 casi d'uso che esistono separatamente ma che dipendono l'uno dall'altro nel modo seguente.

BulkSendUsersToUnit               
    SendUserToUnit   
        AddUserToMandatoryGroups  
            AddUserToGroup

Ciascuno di essi ha convalide, chiamate al deposito e condizioni che si applicano sempre. Fondamentalmente se stavo facendo questo con i servizi sarebbero semplicemente metodi che chiamerei da dove ho bisogno di loro.

Posso / devo iniettare casi d'uso in altri casi d'uso usando DI?

Cosa mi manca qui?

clean-code architecture use-case

posta Dont trust me 30.04.2018 - 06:08

fonte

1 risposta

Leggi altre domande sui tag clean-code architecture use-case

Clean Code e il principio di Least Astonishment Struttura del progetto di progettazione guidata da domini in Java Spring-Boot maven [chiuso]

score 9 · Answer 1

Un caso d'uso non è un metodo.
Un caso d'uso non è un oggetto.
Un caso d'uso non è un livello.

Un caso d'uso è una storia di un utente, utilizzando il software, in un caso particolare.

Quindi non dovrebbe sorprendere che diversi casi d'uso possano riutilizzare lo stesso codice.

Ma forse hai guardato uno dei video ^{^paywalled} dove Bob si distingue come un caso d'uso fa parte della tua architettura.

Bene,nonpreoccuparti.Èsolounnomeperlescatoleinunodeisuoistrati. Ha usato altri nomi per questo :

Questo significa che lo zio Bob ha torto? No. La regola Interact / Use Case / Application Business Rule / Oh-pick-a-name-and-stick-with-it è quella in cui ignori tutte le esigenze della tua applicazione (dettagli) e ti concentri sulle esigenze dell'utente passando per un caso d'uso particolare. Ma questa posizione nel tuo codice non è il caso d'uso. Il caso d'uso è l'intera storia da quando l'utente fa clic su un pulsante quando vede il risultato.

Quindi gli interpreti (o qualunque cosa tu voglia chiamarli) dovrebbero usare altri interesors? Bene, questo è il problema di seguire ASCIUTTO ad estremo. Non sei autorizzato a mettere il codice da AddUserToGroup in nessun altro posto giusto?

Baloney. Se AddUserToMandatoryGroups significa qualcosa di diverso, ha una ragione diversa da voler cambiare, quindi AddUserToGroup fa quindi è ok dare a AddUserToMandatoryGroups il proprio codice add-user. Anche se adesso è un personaggio per la copia del codice del personaggio in AddUserToGroup . Se hai buone ragioni per pensare che questi devono essere in grado di cambiare indipendentemente l'uno dall'altro, non importa se in questo momento sembrano identici. Applicare ASCIUTTO a idee ripetute. Non codice.

Come per Dipendenza Iniezione, che funziona ancora bene quando vuoi disaccoppiare ciò che da quando.

Bulk shitlist = new Bulk(annoyingUsers, bannedForLifeUnit);

Register.OnIveHadAllICanTake( ()-> shitlist.send() );