La "Clean Architecture" di Bob Martin è una regola empirica per tutte le architetture o è solo una delle opzioni?

16

Mi sono piaciuti molto i concetti del video I principi di un'architettura pulita di Uncle Bob Martin . Ma credo che questo modello sia come una combinazione di Fabbrica astratta e Builder modelli al suo interno.

Questo è un modo per scrivere buoni programmi ma non l'unico modo.

Rails e reactjs sono due framework che vengono in mente che non promuovono questo tipo di architettura pulita. Rails si aspetta che la logica aziendale sia nei modelli ( FatModels e SkinnyControllers ) e reagisce all'interno dei componenti. Entrambi gli approcci accoppiano strettamente logica aziendale e codice struttura .

Non trovo nulla di sbagliato in nessuno dei 3 modi. È un giudizio per sceglierne uno.

Ma nel video sento che suggerisce che l'architettura pulita dovrebbe avere un chiaro confine tra logica aziendale e framework. I framework (web, android, ecc.) Dovrebbero essere plug-in che inseriscono in nella logica aziendale. Sottolinea anche le rotaie nel video.

Quindi, L'architettura pulita di Bob Martin è una regola empirica per tutte le architetture o è solo una delle opzioni?

    
posta vedant 02.06.2018 - 07:48
fonte

4 risposte

23

Mentre la "Clean Architecture" va bene e ha molti vantaggi, è importante ricordare che:

  • The Clean Architecture è in gran parte il re-branding e l'evoluzione di Robert C. Martin di approcci correlati come la Onion Architecture di Jeffrey Palermo (2008) e l'Hexagonal Architecture ("Ports and Adapters") di Alistair Cockburn e altri ( < 2008).

  • Diversi problemi hanno requisiti diversi. L'architettura pulita e gli approcci correlati trasformano disaccoppiamento, flessibilità e inversione di dipendenza fino a undici, ma sacrificano la semplicità. Questo non è sempre un buon affare.

Il precursore di queste architetture è il classico pattern MVC di Smalltalk. Questo districa il modello dall'interfaccia utente (controller e vista), in modo che il modello non dipenda dall'interfaccia utente. Esistono molte varianti di MVC come MVP, MVVM, ....

I sistemi più complessi non hanno una sola interfaccia utente, ma possibilmente interfacce utente multiple. Molte app scelgono di offrire un'API REST che può essere utilizzata da qualsiasi interfaccia utente, ad esempio un'app Web o un'app mobile. Questo isola la logica di business sul server da queste interfacce utente, quindi al server non interessa quale tipo di app acceda.

In genere, il server dipende ancora dai servizi di back-end come database o provider di terze parti. Questo è perfettamente a posto e porta a una semplice architettura a strati.

L'architettura esagonale va oltre e smette di fare una distinzione tra frontend e backend. Qualsiasi sistema esterno potrebbe essere un input (origine dati) o un'uscita. Il nostro sistema principale definisce le interfacce (porte) necessarie e creiamo adattatori per qualsiasi sistema esterno.

Un approccio classico per il disaccoppiamento strong è un'architettura orientata ai servizi (SOA), in cui tutti i servizi pubblicano eventi e consumano eventi da un bus dei messaggi condiviso. Un approccio simile è stato in seguito reso popolare dai microservizi.

Tutti questi approcci hanno vantaggi , come rendere più semplice testare il sistema in isolamento (sostituendo tutti i sistemi esterni con cui si interfaccia con le implementazioni fittizie). Semplificano la fornitura di implementazioni multiple per un tipo di servizio (ad esempio, l'aggiunta di un secondo processore di pagamento) o per sostituire l'implementazione di un servizio (ad es. Database Oracle a PostgreSQL o riscrittura di un servizio Python in Go).

Ma queste architetture sono la Ferrari delle architetture: costose e la maggior parte delle persone non ne ha bisogno. La maggiore flessibilità dell'architettura pulita ecc. ha un costo maggiore. Molte applicazioni e in particolare le applicazioni web CRUD non ne traggono vantaggio. Ha senso isolare le cose che potrebbero cambiare, ad es. utilizzando i modelli per generare HTML. Ha meno senso isolare cose che è improbabile che cambino, ad es. il database di supporto. Ciò che è probabile che cambi dipende dal contesto e dalle esigenze aziendali.

I quadri fanno ipotesi su cosa cambierà. Per esempio. React tende ad assumere che il design e il comportamento di un componente cambino insieme, quindi non ha senso separarli. Pochi quadri presumono che tu voglia cambiare il quadro. Pertanto, i framework presentano una quantità di lock-in. Per esempio. Il fatto che Rail faccia affidamento sul modello di registrazione attiva (molto avvantaggiato!) Rende difficile l'impossibilità di cambiare la strategia di accesso ai dati al modello di repository (spesso superiore). Se le tue aspettative di cambiamento non corrispondono al quadro, l'utilizzo di un quadro diverso potrebbe essere migliore. Molti altri framework web non fanno alcuna ipotesi sull'accesso ai dati.

    
risposta data 02.06.2018 - 11:43
fonte
16

I really liked the concepts in the video The Principles of Clean Architecture by Uncle Bob Martin. But I feel like this pattern is like a combination of Abstract Factory and Builder patterns at its core.

Non chiudere nemmeno.

Quando guardi questo:

Staiguardandoildesigndiungraficooggetto.Questodeterminacosasadicosa.Ciòchemancainquestastoriaècomeèstatocostruitoilgraficodell'oggetto.Scusamanonlotroveraiqui.Nonc'èalcunamenzionedicostruzione.

Puoicostruiretuttoquestosenzafabbricheecostruttoriastratti.Losoperché l'ho fatto . Non ho nemmeno deciso di evitarli. Li amo. Non mi è capitato di averne bisogno. Ho appena usato il reference passing. Iniezione di dipendenza è il termine di fantasia per questo.

In effetti, potrei costruire tutto ciò che vedi in quel diagramma in main. Quindi basta chiamare un metodo su un oggetto per iniziare il tutto ticchettando.

Ora le cose devono esistere prima di poterle inserire in altre cose. Ho esplorato questo qui e gli ho dato questo grazioso diagramma:

Epuoicrearetuttociòsenzanemmenolasciaremain().

Vorreiraccomandarel'usodicostruttoriefabbrichequandosivuolerompereunapiladicodicedicostruzioneproceduraleinbeipezziconcettualididimensionidelmorso.Manonc'ènullanell'architetturapulitaoinnessunadellealtrearchitetturedibuzzwordcherichiedechetufaccia.Quindisevuoirestareconmain(),bene.Perfavore, abbi pietà .

Is “Clean Architecture” by Bob Martin a rule of thumb for all architectures or is it just one of the options?

Considero l'architettura pulita una parola d'ordine usata per guidare le persone verso un blog e un libro. Quel blog e il libro hanno ottime spiegazioni di architetture più antiche molto simili con nomi più vecchi usati per guidare le persone verso blog più vecchi e libri più vecchi. In particolare cipolla e porte e adattatori. Nessuno dei quali è l'unica opzione architettonica che possiedi.

Mi piace lo zio Bob perché è un oratore e un autore fantastici. Mi fa pensare a cose che altrimenti non avrei. Ma se lasci che ti trasformi in uno zelota religioso che insiste che tutto debba essere fatto a modo suo, scoprirai rapidamente che la documentazione di aggiornamento è la più vicina che ti permetterò di ottenere il mio codice.

Le architetture della buzzword sono utili quando hai un codice di lunga durata che deve persistere mentre il mondo cambia intorno ad esso. Questo è quando brilla. Se il mondo è stabile rispetto al codice, allora stai facendo le cose di fantasia senza una buona ragione.

Indipendentemente da quanto qualcosa di fantastico appaia, c'è un contesto in cui puoi metterlo dentro che lo renderà assurdo. Spiacente, questo non è un proiettile d'argento.

But in the video I feel he suggests that clean architecture should have a clear boundary between business logic and frameworks. Frameworks (web, android, etc.) should be plugins that plug in to to the business logic. He even subtly mocks rails in the video.

Hai ragione. Lui fa. Lo zio Bob ritiene che le strutture possano essere trattate come librerie. E loro possono Ma anche quella decisione ti costa qualcosa.

Ciò che il signor Martin sta cercando di preservare è uno spazio in cui il linguaggio generale è ancora generale. Lo lasci quando diffondi un quadro ovunque. Quando lo fai, ti stai dirigendo verso il morphing del tuo linguaggio in qualcosa chiamato un linguaggio specifico del dominio. HTML è un linguaggio specifico del dominio. Fa il suo lavoro molto bene, ma ci sono altri lavori che non può fare affatto.

Finché i tuoi bisogni saranno anticipati dal framework, le cose andranno molto bene. È bello avere i tuoi bisogni anticipati. Ti mette in una scatola che mantiene le cose semplici. Basta capire cosa stai dando per ottenere questo. Se diffondi Spring ovunque, non puoi più pubblicizzarlo come un lavoro Java. È un lavoro Java / Spring. Potrei dire la stessa cosa di Ruby e Rails ma Rails ha mangiato il pranzo di Ruby molto tempo fa.

    
risposta data 02.06.2018 - 15:43
fonte
4

Per citare il video:

"You don't want to do mail merges in SQL."

seguito da:

"I actually saw a SQL stored procedure which was an entire mail merge"

L'architettura, come la fusione della posta, è solo un'opzione tra molte.

Ciò che non è opzionale sono i problemi che l'architettura sta cercando di risolvere.

Se comprendi quali problemi causa la fusione della posta SQL rispetto ad altre soluzioni, la tua scelta architettonica verrà informata e anche se sei costretto a scegliere soluzioni "cattive", ne sarai consapevole e attenuerai le carenze.

Se segui uno stile architettonico solo perché è ben pensato, allora potresti commettere errori e incontrare gli stessi problemi.

    
risposta data 02.06.2018 - 21:04
fonte
0

"Clean Architecture" è sicuramente "solo" una delle opzioni. Direi che è una delle opzioni sbagliate per la maggior parte dei progetti, specialmente per i progetti orientati agli oggetti.

Ecco un'analisi frase per frase dell'articolo di Uncle Bob su Clean Architecture con i motivi della dichiarazione di cui sopra:

L'architettura pulita da una prospettiva orientata agli oggetti

    
risposta data 08.06.2018 - 10:06
fonte

Leggi altre domande sui tag