Mi sono piaciuti molto i concetti del video The Principles of Clean Architecture di Uncle Bob Martin. Ma sento che questo modello è come una combinazione di modelli astratti di Factory e Builder nel suo nucleo.
Neanche vicino.
Quando guardi questo:
Stai guardando il design di un grafico a oggetti. Questo impone ciò che sa di cosa. Ciò che manca in questa storia è come è stato costruito quel grafico a oggetti. Mi dispiace ma non lo troverai qui. Non vi è alcuna menzione di costruzione.
Puoi costruire tutto questo senza fabbriche e costruttori astratti. Lo so perché l' ho fatto . Non ho nemmeno deciso di evitarli. Li amo. Non mi è mai capitato di averne bisogno. Ho appena usato il passaggio di riferimento. Iniezione di dipendenza è il termine elegante per questo.
In effetti, potrei costruire tutto ciò che vedi in quel diagramma in principale. Quindi basta chiamare un metodo su un oggetto per avviare il tutto ticchettio.
Ora le cose devono esistere prima che tu possa spingerle in altre cose. L'ho esplorato qui e gli ho dato questo piccolo diagramma carino:
E puoi costruire tutto ciò senza nemmeno andartene main().
Consiglierei di usare costruttori e fabbriche quando si desidera scomporre un mucchio di codice di costruzione procedurale in bei pezzi concettuali di dimensioni ridotte. Ma non c'è nulla nell'architettura pulita o in nessuna delle altre architetture di parole d'ordine che ti richiedano. Quindi se vuoi restare con te main(), bene. Per favore, abbi pietà .
"Clean Architecture" di Bob Martin è una regola empirica per tutte le architetture o è solo una delle opzioni?
Considero Clean Architecture come una parola d'ordine usata per guidare le persone verso un blog e un libro. Quel blog e quel libro hanno ottime spiegazioni di architetture più vecchie molto simili con nomi più vecchi usati per guidare le persone verso blog più vecchi e libri più vecchi. In particolare cipolla, nonché porte e adattatori. Nessuna delle quali è l'unica opzione architettonica che hai.
Mi piace lo zio Bob perché è un oratore e un autore pubblici fantastici. Mi fa pensare a cose che altrimenti non avrei. Ma se lasci che ciò ti trasformi in un fanatico religioso che insiste sul fatto che tutto deve essere fatto a modo tuo, scoprirai rapidamente che l'aggiornamento della documentazione è il più vicino che ti lascerò arrivare al mio codice.
Le architetture di parole d'ordine sono utili quando si ha un codice di lunga durata che deve persistere mentre il mondo cambia attorno ad esso. Questo è quando brilla. Se il mondo è stabile rispetto al codice, allora stai facendo cose fantasiose senza una buona ragione.
Non importa quanto qualcosa di fantastico sembri, c'è un contesto in cui puoi inserirlo che lo renderà assurdo. Spiacente, neanche questo è un proiettile d'argento.
Ma nel video ritengo che suggerisca che un'architettura pulita dovrebbe avere un chiaro confine tra logica di business e framework. I frame (web, android, ecc.) Dovrebbero essere plug-in che si collegano alla logica aziendale. Nel video prende in giro anche le rotaie.
Hai ragione. Lui fa. Lo zio Bob ritiene che i framework possano essere trattati 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 la tua lingua di uso generale è ancora generale. Ti arrendi quando diffondi un framework ovunque. Quando lo fai, stai seguendo il percorso di trasformare la tua lingua in qualcosa chiamato una lingua specifica del dominio. HTML è un linguaggio specifico del dominio. Fa molto bene il suo lavoro ma ci sono altri lavori che non può fare affatto.
Finché le tue esigenze sono anticipate dal quadro, le cose andranno molto bene. È bello avere le tue esigenze anticipate. Ti mette in una scatola che semplifica le cose. Basta capire a cosa ti stai arrendendo per ottenere questo. Se diffondi Spring ovunque non puoi più pubblicizzarlo come 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.