Sono daccordo con il recente post di Mauro e quindi con l'affermazione di Tommaso: "Se non è semplice c'è qualcosa che non va". Questa è stata la mia impressione in diversi lavori che ho visto, ma qui prepotentemente si insinua un altro problema: le performance.
Si, abbiamo macchine da 4GHz, ma certe scelte costano care anche su macchine superveloci.
Si, entro 5 anni arriveremo a 80 core, dice Intel (poi quando parlavo dei 16 core mi davano del visionario), ma sfruttarli per bene non è affatto semplice e gli strumenti sono ancora pochi (tra l'altro questi saranno proprio gli argomenti di una delle mie sessioni ai Community Days).
Ma ...
Ma recentemente ho toccato con mano che alcune scelte architetturali costano in performance e sono di tangibile fastidio all'utente che usa l'applicazione.
Factory, Proxy, MVC, MVP, Adapters, ... sono fantastiche soluzioni by design ... se si chiamano pattern significa proprio che sono stati usati con successo da migliaia di developer e quindi su questo non si discute. Il problema è chi li usa 
.
- La prima considerazione è che il disegno dell'applicazione è e rimarrà un passo fondamentale per la creazione di una applicazione, e che quegli strumenti sono validissimi.
- La seconda considerazione è che lo sviluppatore e l'architetto devono dialogare per capire fin dalla stesura dell'architettura per capire quali possano essere i colli di bottiglia e non finire col piangere davanti ad un profiler.
- La terza considerazione è che le performance vanno misurate perché è troppo facile dare la colpa al mancato uso di StringBuilder o all'architetto eccentrico, ma devo ribadire che se alla performance non ci si pensa fin dall'inizio, alla fine si fa prima a riscrivere, il che è quanto di peggio possa accadere.
- La quarta considerazione è che i problemi di performance dovuti all'architettura ci sono a prescindere dall'ambiente di sviluppo e possono accadere anche con la programmazione nativa in C++. Solo che chi programma in C++ non ha strumenti insiti nel linguaggio per componentizzare (i componenti ci sono se si usa COM, Corba, Framework, ...) e quindi tipicamente l'architettura è più spartana.
- Infine quello che ritengo sarà la soluzione ottimale e il miglior compromesso: la generazione di codice. Alcune scelte architetturali sono legate all'uso di tecnologie come Reflection, potenti ma anche arma a doppio taglio.
Concludendo, non sempre fare i "perfettini" con l'architettura paga, anzi tutt'altro.
Quindi tornando al post di Mauro aggiungo che l'architettura non deve essere solo semplice ma anche un compromesso con le tecnologie e i linguaggi che si stanno utilizzando. Non credo alla pura architettura riusabile meno che mai in modo trasversale sul Framework, su Java, su COM, etc. L'architettura si deve 'sporcare', quando è necessario, perché il nostro è il regno della tecnocrazia.
Paragone con un algoritmo di calcolo: lo scrivo in C++ e lo traduco in C# (o viceversa).
Funziona? Si. È efficicente? No, nella gran maggioranza dei casi perché lo strumento ha delle differenze notevoli da cui non possiamo prescindere.