Architettura pulita: gli utenti dovrebbero andare nel livello caso d'uso o nel livello dominio?

6

Recentemente ho letto questo articolo su Clean Architecture, mentre sto cercando di uscire da alcune solite abitudini OO (design dell'interfaccia ovunque, ma cosa fare ???), e programmare qualcosa che descriva cosa fa il sistema invece di come il sistema è costruito (per parafrasare "Zio" Bob).

Una volta che l'articolo raggiunge il livello caso d'uso, l'autore menziona che ha lasciato gli utenti fino a quel livello perché gli utenti sono specifici per l'applicazione, quindi crea un riferimento (che davvero non credo di avere) a come se fosse un gioco da tavolo non avrebbe utenti, ma avrebbe ancora tutti gli oggetti dominio, nel suo caso ordini e prodotti.

Ma il modo in cui lo vedo, in un'app Web (alcuni SaaS leggeri) fanno parte del dominio. Immagina un cloud document store come Dropbox: memorizzano i documenti, quindi sembra che un documento sia sicuramente un oggetto dominio. Ma hanno anche utenti, no? La loro attività comporta la memorizzazione di documenti per gli utenti e senza gli utenti non violerebbe un aspetto della loro attività?

Semplicemente non capisco perché gli utenti non siano considerati parte del sistema allo stesso modo dei documenti o di altre cose. Qualcuno può chiarire questo principio e le ragioni che lo giustificano?

    
posta Adam 08.12.2014 - 03:18
fonte

1 risposta

8

L'autore fa la distinzione tra ciò che è nel "gioco da tavolo" o non con il seguente esempio:

eBay the website and eBay the board game both need buyers, sellers, items, and bids – but only eBay the website needs users, sessions, cookies, login/logout etc.

Guarda come menziona "compratori" e "venditori"? Questi sono solo nomi diversi per "utenti", ma inseriti nel contesto aziendale.

Il punto principale della separazione è che il tuo modello di business (o come dice zio Bob, "regole di business agnostiche delle applicazioni") non ha bisogno di conoscere i metodi di autenticazione e autorizzazione dell'utente corrente, o che ha una password, o usa Facebook o Google. Tornando all'esempio di eBay, l'azienda deve solo sapere che, nel contesto dell'Ordine X, l'utente Y è il compratore mentre l'utente Z è il venditore. Questo è ciò che è importante per far funzionare il business: questo è ciò che fa l'applicazione.

Ricorda sempre che l'idea è di rendere le regole aziendali completamente indipendenti dal meccanismo di consegna. Puoi avere utenti come parte del tuo modello di business, non c'è niente di male in questo - Dropbox ha certamente bisogno, come hai sottolineato. Ma assicurati di rimuovere tutto ciò che riguarda il modo in cui l'utente interagisce con il sistema. Questo livello di dettaglio può essere affrontato principalmente dal meccanismo di consegna e in parte dalle regole aziendali specifiche dell'applicazione.

Ad esempio, in alcune app che ho creato, controllo le autorizzazioni dell'utente all'interno dei miei casi d'uso, ma i metodi di autenticazione sono disaccoppiati come plugin da implementare al di fuori delle applicazioni. Questo mi ha permesso di aggiungere facilmente opzioni di accesso come Faceebok, Twitter e Google, senza influire sulla struttura delle applicazioni.

    
risposta data 08.12.2014 - 03:53
fonte

Leggi altre domande sui tag