E’ mai capitato a qualcuno di voi di dover dare un “soprannome informale” ad un proprio progetto/solution?

Onestamente io cerco sempre di dare estro && personalità ai miei progetti, perchè parto dall’idea che un architect sia un pò come un compositore musicale. Così la mia “melodia” ho deciso di chiamarla “ALICE“; il tutto è nato in maniera casuale, nel bel mezzo di una riunione.

Ormai è un anno abbondante che mi dedico allo sviluppo di soluzioni per piattaforma Microsoft Dynamics CRM, e da qualche mese sono impegnato in un progetto di larga scala insieme ad un team di miei colleghi. La mia attività principale è focalizzata su una parte dell’intero progetto, e senza entrare nello specifico, mi occupo di tutta l’infrastruttura di comunicazioni tra CRM e altri sistemi e viceversa. In tutto questo “marasma” mi è stato chiesto di ideare l’architettura sulla quale sono basati tutti i servizi. Tralascio le specifiche tecniche su tecnologie utilizzate e architetture SOA (anche per una questione di privacy!), ma vorrei concentrarmi sul topic di questo post: il naming!

Quando ho immaginato mentalmente il mio servizio pensavo a un “qualcosa” altamente generico, basato su meccanismi di reflection e codedom. Sono partito così dal domain model della solution : Wonderland. Ho strutturato poi i vari servizi che si occupano di Data Access Layer, Entity Framework, Configuration Storage, etc…e sono infine giunto a quello che io chiamo “il mio gioiellino”, il servizio pilota di tutti i servizi : “Alice”. La correlazione tra servizio e dominio è nata così spontaneamente: Alice non poteva che risiedere nel “paese delle meraviglie”!!!!!

Sarà questa la vera storia???Come in tutte le fiabe lascio al lettore la migliore interpretazione di quanto letto, conscio e speranzoso che almeno uno di essi colga la vera lettura di questa righe.

 

l.

Inizierei il tutto con il link alla Wikipedia circa la definizione di Design Pattern.

Come si può facilmente evincere dalla descrizione della Wikipedia, il contesto dei design pattern è architetturale e non solamente applicativo. Si cerca quindi mediante dei modelli consolidati, di risolvere problematiche di sviluppo ricorrenti : potremmo, in maniera semplicistica, definirli “snippet architetturali” (spero di non essere fucilato per questo azzardo! ).

La prima domanda che sorge spontanea ai più è : perchè impiegare i pattern? La riposta è alquanto semplice, e per questo mi appoggio ad una frase utilizzata da Riccardo Golia in un articolo su MSDN :

“Per minimizzare il lavoro da svolgere, gli sviluppatori meno esperti solitamente tendono a ricorrere a tecniche non object-oriented (non ultimo, il famigerato copia-e-incolla), con il risultato di duplicare parti di codice e di introdurre in modo più o meno voluto accoppiamento e dipendenze tra gli oggetti. Gli architetti e gli sviluppatori con più esperienza tendono invece a preferire le soluzioni object-oriented che in passato si sono rivelate vincenti ed efficaci. continua“

Lascio classificazione e cenni storici alla lettura del sopracitato articolo che, a mio avviso, è il migliore che abbia letto.

Buona lettura

L.

Ho deciso dopo tempo, molto tempo, addirittura troppo tempo, di aprire un mio blog personale in cui poter discutere e cercare "di dire un pò la mia" sull’Agile Development, Design Pattern e C#.

Diciamo che questo è un’impegno personale di formazione e , in un certo senso, di "dovere" dopo alcuni anni di letture appassionate di Blogs altrui, che non mancherò certamente di citare!

Vorrei iniziare questa mia avventura premettendo che alternerò post in italiano e in inglese, per accontentare un pò tutti…ma ci terrei particolamente a ringraziare un mio collega di lavoro, MatteoSp, per avermi aperto gli occhi e soprattutto instradato verso "la retta via" (dello sviluppo!).

Perciò incrocio le dita e spero che questa avventura possa portare soddisfazione a me, ma soprattutto aiuto, illuminazione, spunti di discussione o qualsiasi altra cosa a chi leggerà quanto scriverò!

L.