Si potrebbe dire che in genere un sistema informatico comprende varie applicazioni che dialogano con uno strato di dominio applicativo (entità e processi) le quali si interfacciano con infrastrutture che permettono di azionare servizi o persistere/recuperare dati. Lo scopo - in genere - è quello di nascondere al mondo applicativo il tecnicismo delle infrastutture in modo da poterle sostituire/manutenerle con maggiore semplicità.
Una tendenza prettamente implementativa/architetturale è quella di costruire facciate - facade - verso sistemi complessi in modo da portare verso l'alto un'interfaccia semplicificata. Una tendenza prettamente implementativa/architetturale è anche quella di centralizzare/generalizzare/generichizzare le funzioni in modo da rendere quanto più veloce una variazione che impatti trasversalmente su tutte le funzionalità/casi d'udo che risolve.
Mi piacerà ora indicare con gioco della superficie di contatto il rapporto tra il numero delle funzionalità/metodi/entry point che un component espone al/ai consumer e il numero dei casi d'uso che il componente risolve al consumer stesso. Dirò che la tendenza a generalizzare significa la riduzione di tale rapporto perchè un metodo risolve più casì d'uso (1/n). Quando a mio avviso ha senso cercare la generalizzazione e quando si dovrebbe accettare di non farlo e non cadere in tentazione?
Il problema non è dire se ha senso o non ha senso ridurre tale gioco ma credo si deppa parlare di pericolsità o meno delle generalizzazioni. A mio avviso c'è ragione di ridurla quando i casi d'uso sono finiti/definiti e non mutabili. E' questa la casistica di facade/wrapper verso componenti che trattano problemi di insfrastutture (accesso al dato, mappatura dati, proxy versi sistemi remoti esterni). E' rischiuso invece quando si tratta di componenti di Business (processi, entità e orchestrazioni) in quanto le esigenze di business sono decisamente mutabili.
Quanto più tende a 1 il gioco della superficie di contatto e tanto maggiore sarà l'effort per introduzione modifiche trasversali ma sarà più semplice introduzione variazioni per specifici contesti/casi d'uso senza impattare su tutta la superficie dei casi d'uso... quindi minore possibilità di introduzione di malfunzionamenti non previsti e/o ipotizzabili. Occorre mettere sul piatto della bilancia le casistiche in cui in un progetto dobbiamo fare refactoring trasversale e quelle in cui invece dobbiamo affrontare solo variazioni di specifici casi d'uso. In fase di startup sono decisamente maggiori i primi... e quindi la tentazione di introdurre quante più generalizzazioni... ma a tendere un progetto si stabilizza nella forma ma continuerà a richiedere variazioni specifiche di specifici casi d'uso in quanto le esigenze business saranno sempre soggette a variazioni.
- oO( Mumble, questo è un concetto che sicuramente merita un approndimento ) -
posted @ giovedì 18 gennaio 2007 10:54