Anche se con un pò di ritardo, d' altronde ad un week-end al mare non si può mai rinunciare, anche stavolta ecco una mia recensione, in particolare quella legata all' evento tenuto da DotNetMarche su DDD. Il meeting è stato articolato in due sole sessioni onde evitare, dato il caldo torrido, incontrollabili surriscaldamenti cerebrali ; concordo quindi appieno con la stesura dell' agenda anche se vorrei evidenziare IMHO come l' inizio di un meeting non debba subire pesanti ritardi a causa del ritardo di uno o due partecipanti, in quanto "sforando" poi alla fine si perdono per strada molti piu pezzi. Per quanto concerne gli speaker, da Janky ho avuto le stesse conferme dei meeting passati, vale a dire ottima abilità di comunicazione unita a quel mix di verace sarcasmo  che rendono viva l'attenzione durante ogni sua sessione; non avevo mai visto GianMaria nei panni di speaker e devo dire che gli calzano proprio a pennello ; molto chiaro e sicuro nell' esposizione, riesce a far passare molto bene il proprio "vangelo".

Veniamo adesso al contenuto vero e proprio delle sessioni; la prima, quella di Giancarlo ha dispensato a destra e a manca pilllole di Domain Driven Design: nella parte iniziale è stato mostrato velocemente l' approccio UML con il quale modellare il dominio, evidenziando l' importanza e l'accuratezza con la quale deve essere effettuata la traduzione dal modello generato in fase di analisi e business requirement verso l' object model vero e proprio. Devo dire che la conoscenza di UML è propedeutica per comprendere veramente le, a volte sottili, differenze che si verificano tra i due modelli. Janky ha mostrato poi i desing pattern con i quali l'architetto può modellare il domain layer vale a dire,in ordine puramente casuale:

1. Domain Model
2. Table Module
3. Transaction script

Fatto ciò Janky ha cominciato tramite un semplice esempio ad effettuare alcuni esempi di modellazione evidenziando pregi e difetti di ogni soluzione; a parte i "soliti" schemi architetturali il messaggio che emerge da questa sessione è l' importanza che rivestono nella modellazione delle entità sia le specifiche funzionali che quelli strutturali (sicurezza, logging...); le specifiche strutturali non devono alterare la definizione delle nostre entity, in quanto il core domain deve rimanere agnostico nei loro confronti; da evidenziare al tempo stesso come questo non debba portare alla definizione di Domain Model Anemici , soluzione che in passato sembrava aver preso troppo piede e che personalmente trovavo troppo avversa nei confronti dell' OOD. Last not least la perla finale che va sotto il nome di Web Client Software Factory con particolare riferimento al Page Flow e al relativo meccanismo di persistena offerto da WF basato su SqlServer con alcuni accenni (è piu forte di lui) al View Presenter.

La seconda sessione, quella di GianMaria, ha inizialmente ricalcato alcuni concetti espressi anche da Janky, della serie repetita iuvant, per poi addentrarsi nei tortuosi meandri di SOA e AOP. La prima parte ha evidenziato come ci sia (come ormai ovunque ) un disallineamento tra la definizione di un object model basato su Domain Model e l' ottica SOA; GianMaria ha evidenziato la necessità di avere una differente granularità, tra un object Model fine adatto a contesti non orientati ai servizi, e un Object Model a granularità grossa che migliora l' efficienza in un contesto distribuito. Sono stati presi in rassegna alcuni pattern, fra i quali:

• DTO:utilizzato al fine di aggregare dati provenienti da più oggetti remoti, in modo da avere ad esempio sul client un domain model piu snello
• Remote Facade (meno male che lo scrivo perchè ogni volta lo sento pronunciare diversamente): definendo una facciata remota a granularità grossa riesce a schermare il nostro dominio all'esterno aumentandone flessibilità e prestazioni
• Factory: centralizza la costruzione di oggetti al fine di demandarla ad un metodo apposito disaccoppiando la costruzione di oggetti dal reale utilizzo
• Decorator: utilizzato per incorporare funzionalità aggiuntive a runtime

Detto ciò GianMaria è passato ad esporre i concetti base sui quali si fonda AOP: SOC, IoC, Injection. Quello che mi ha colpito è proprio il diverso approccio (oserei dire duale) con il quale AOP rispetto ad OOP affronta il problema. Oltre alle definizione delle classi, AOP, riccorrendo ad un approccio modulare, introduce quegli aspetti trasversali a molti dei nostri oggetti quali ad esempio Logging e Transazionalità. Dopo questa doverosa premessa teorica si è passati all'azione vera e propria in cui GianMaria tramite un processo di refactoring evolutivo ha mostrato come eliminare le varie dipendenze funzionali da un esempio preso in esame, utilizzando log4j e Spring.net; l' aggiunta di particolari aspetti applicativi avviene comodamente agendo sul file di configurazione iniettando i behaviors senza dover ricompilare l'applicazione. Insomma il famoso Principio di Hollywood che sta alla base dell' Inversion of Control porta ad avere basso accoppiamento rendendo la nostra architettura a plugin. Dopo tutti questi paroloni non bisogna dimenticarsi, cosa che hanno più volte espresso entrambi gli speaker che per realizzare un software per gestire i sacchi di patate dell' ortofrutticolo sotto casa vanno più che bene i dataset tipizzati!!!!!!

Concludendo da una breve analisi dei partecipanti l' evento piu che marchigiano si è trasformato in italiano, consacrondolo definitivamente come successo; l' unico consiglio che mi sento di dare è il rispetto degli orari dell' agenda e l'estrazione dei premi a priori calcolando che sicuramente nessuno viene al meeting solo per vincere una licenza...

Vox populi, vox Dei