Ok, cominciamo col dire che non ho alcuna intenzione di coniare una nuova buzzword.
Ormai è un po' di tempo che sto lavorando continuativamente con NHibernate, approcciando lo sviluppo di applicazioni che fortunatamente non hanno uno schema di DB già fatto, quindi con il pieno controllo di quello che l'accesso ai dati persistiti.
Probabilmente questo mio post susciterà qualche reazione in alcuni di coloro che lo leggeranno, ma voglio comunque fare una riflessione.
Orbene, DDD è l'ormai famoso acronimo do Domain Driven Design, ovvero quella pratica di design architetturale che si basa sulla costituzione di un modello di dominio object oriented (e sì, con tutti i bla bla bla di contorno fra cui la postilla importantissima la quale recita più o meno: _NON_ è l'unico modo di progettare un'architettura enterprise, valutare bene i pro ed i contro, eccetera, eccetera, eccetera).
Il modello di dominio in salsa object oriented è un approccio che "teoricamente" dovrebbe fornire tutta la potenza del paradigma OO nel concettualizzare entità e interazioni (per non chiamarle relazioni che magari fa confusione...) fra queste. Quindi classi, associazioni, ereditarietà, incapsulamento, collezioni e via discorrendo.
Bè... falso come Giuda ;-)
No dai, sto esagerando, però siamo a metà strada...
Quello che definisco ADD starebbe per Adaptive Driven Design ovvero qualcosa che faccia pensare all'attività di "adattamento" di qualcosa (che più avanti specificherò) verso qualcos'altro.
Il qualcosa che deve adattarsi è proprio il modello di dominio, o almeno la "mano libera" che abbiamo nel disegnarlo, che tanto libera in realtà non è, almeno utilizzando il framework più famoso in ambito DDD, ossia NHibernate, ma più in generale approcciando la persistenza del dominio stesso su supporto non deperibile (il disco fisso...).
NHibernate è appunto "the bridge over trouble water" (cit.), ovvero quello strato software (non facciamola tanto lunga suvvia) che permette di mappare un modello di dominio OO su uno schema relazionale ospitato in un RDBMS, che volenti o nolenti, oggi come oggi, rimangono il sistema più sicuro ed efficace di "scrivere" e manutenete su disco i dati (e poi non vogliamo mica mandare sul lastrico svariate migliaia di lavoratori, vero?).
Sgombriamo il campo da equivoci: non ce l'ho con NHibernate, ce l'ho con la letteratura dell'ingegneria del software, soprattutto quella che si occupa di DDD.
A mio umile e modetso modo di vedere bisognerebbe dare, a chi si affaccia per la prima volta al mondo del modello di dominio, un messaggio molto chiaro: il mondo delle favole esiste solo a Fantasilandia, nani compresi.
NHibernate, povero diavolo, fa quello che deve fare, e lo fa piuttosto bene, ovvero mappare un grafo di classi su uno schema relazionale, con tutte le sue associazioni, pure bidirezionali, ereditazioni (ma si dirà così?), collezioni, eccetera, eccetera, eccetera. Altrettanto non v'è dubbio che la potenza della Unit of Work e dell'Identity Map, siano ormai irrinunciabili in moltissimi scenari, come le mirabolanti funzionalità di caching che il buon Gavin King ha voluto offrirci (e il primo che mi chiede chi è costui lo sparo...), e potrei continuare.
Ma c'è un ma (ma va?). E cioè che con tutta la perizia, la buona volontà, l'applicazione, il rigore, e chi più ne ha più ne metta, la ormai famigerata "Impedance Mismatch" (ma poi perchè sarebbe femmninile qualcuno me lo dovrà spiegare prima o poi), è davvero dura di comprendonio e in molti casi ci si deve arrendere.
Arrendere significa (a casa mia...) "adattarsi", da qui l'acronicmo ADD. Il che a sua volta significa: scordatevi di disgenare un modello di dominio sbizzarendovi con la object orientation, perchè la maggior parte delle volte vi triverete di fronte ad un costrutto che sarà impossibile (o comunque altamente sconsigliabile, che è la stessa cosa alla fine) mappare su uno schema relazionale, anche se quest'ultimo non ve lo ha imposto nessuno e lo state progettando da zero, esattamente come il modello ad oggetti.
E così ad esempio la delusione (gli ohhhhhh desolati si sprecano) nell'apprendere che sì, NHibernate, in quanto ORM a modino, supporta le relazioni molti-molti, ma per carità del cielo _NON USATELE MAI_, usate sempre due uno-molti con una entità di dominio ponte (ehi, aspetta un attimo... ma è quello che faccio già col modello relazionale!!!! Vero fratello, vai in pace). O per esempio scoprirete vostro malgrado che le entità DettaglioQuaccheccosa si sprecano.
Ovviamente sto esagerando, ma il succo in fondo in fondo è proprio questo: dovrete adattarvi, turarvi il naso ogni tanto, sporcarvi le mani e alla fine con la stampa del modello di dominio nella mano destra, quella dello schema del DB nella sinistra, avrete la netta sensazione di stare osservando due gemelli diversi, eterozigoti, certo non due cugini di secondo grado...
I libri sono tanto belli, io ad esempio avrò un paio di stipendi posizionati nella sezione della mia libreria dedicata al mondo dello sviluppo software, ma non prendeteli come oro colato. Venite ai workshop (di tutte le community, anche quelle fresche ed alternative <g>), ascoltate gli speaker che come noi il codice lo scrivono, quello vero che va in produzione, fate anche qualche corso specifico. Vedrete che la vità, magari non vi sorriderà ancora, ma forse un po' meno incazzata lo sarà di certo.
Saluti.