Alkampfer's Place

Il blog di Gian Maria Ricci
posts - 659, comments - 871, trackbacks - 80

My Links

News

Gian Maria Ricci Mvp Logo CCSVI in Multiple Sclerosis

English Blog

Tag Cloud

Article Categories

Archives

Post Categories

Image Galleries

I miei siti

Siti utili

Framework per DDD

Questo post era ancora in draft nel mio HD ed è tornato alla ribalta con una discussione con Stefano. Si parlava di realizzazioni di framework per DDD, argomento quantomeno caldo e anche controverso.

Partiamo dal presupposto che nella community è grande l’interesse per il DDD, ma scarseggia il codice, soprattutto per pattern più complessi come Event Sourcing e CQRS, quindi sembra sicuramente interessante costruire un framework DDD per supportare questi pattern, ma la domanda vera è: è possibile?

A mio avviso la risposta è no, trovo infatti molto difficile pensare a come possa essere strutturato un framework utilizzabile in produzione per DDD da team e persone differenti. I problemi sono troppi e soprattutto secondo me si va a cozzare con il concetto stesso di DDD, il cui valore è soprattutto nel Modello e non nell’implementazione. Di questo ho già parlato in un recente post, ma la discussione con Stefano ha riportato questo draft a galla e quindi volevo fare alcune considerazioni ulteriori.

La prima difficoltà nella realizzazione di un framework per DDD è: che tecnologia usare? Se partiamo dal concetto di BOUNDED CONTEXT, e lo applichiamo in maniera seria, ci si rende conto che ogni BOUNDED CONTEXT fa storia a se, qualcuno potrebbe essere basato su CQRS, un altro BOUNDED CONTEXT potrebbe leggere semplicemente i dati con un DataReader e fare Update secche ad un db relazionale, altri potrebbero basarsi su NO SQL, o su file XML etc etc. Se volessimo creare un framework per DDD dovremmo pensare a tutte le possibili implementazioni e combinazioni (CQRS con DB NO SQL, CQRS con DB Relazionale, ORM Su DB Relazionale, Accesso Diretto su NO SQL, Accesso Diretto su DB Transazionale, etc etc) e stiamo parlando solamente della parte di storage; se iniziassimo a parlare anche di messaggistica, di come separare tra tier andremmo ad aprire un vaso di pandora da cui difficilmente potremo districarci. Trovo difficile creare una infrastruttura cosi flessibile da poter “pluggare” queste tecnologie in maniera trasparente, ma soprattutto trovo “poco utile” cimentarsi in questa impresa, andando quindi a risolvere probabilmente una parte “non core” del DDD, ovvero l’implementazione.

La seconda difficoltà è che ogni BOUNDED CONTEXT può avere modelli strutturati in maniera fortemente differente, se siamo in una parte “core” dell’applicativo, con Business Rules che cambiano spesso e che sono complesse, CQRS ed oggetti senza proprietà pubbliche sono sicuramente la scelta migliore. Per altri BOUNDED CONTEXT, con meno regole e più legati ai “dati” che alle “operazioni”, il modello potrebbe essere molto più anemico, lasciando delle operazioni a carico dei Servizi. Il nostro ipotetico framework dovrebbe quindi poter operare con due implementazioni completamente differenti di entità, con il rischio di realizzare qualche cosa che non sia effettivamente omogenea.

Il terzo scoglio è che un framework corre il rischio di trovarsi a fare delle scelte idiomatiche, ovvero legate alla tecnologia su cui esso è basato. Se ad esempio creiamo un modello di interrogazione dei dati basato su LINQ, sarà impossibile portarlo in altre tecnologie dove LINQ non è presente, oppure troveremo molte difficoltà se il motore di persistenza non implementa in maniera veramente completa il provider (leggi NHibernate). In caso di oggetti senza proprietà pubbliche poi, LINQ non è utilizzabile indipendentemente dal provider.

La conclusione è che la community DDD è nuova e probabilmente quello che serve è una serie di “reference implementation” con casi molto semplici, il cui scopo è semplicemente permettere alle persone di avere dei punti di partenza sui cui basarsi. Lo scenario potrebbe essere questo: “mi trovo in una situazione in cui non posso usare NO SQL, il cliente vuole solamente SQL Server, debbo fare CQRS ed Event Sourcing. Da dove parto?”. Quello che serve è una serie (due o tre almeno) di possibili implementazioni semplici di una simile struttura, senza la presunzione di framework, esattamente come avviene nel libro del Pattern del GoF.

Quindi a mio avviso la community DDD avrebbe bisogno non di framework, ma di una maggiore formalizzazione dei pattern più avanzati (CQRS, Event Sourcing, Domain Events, etc) con reference implementation, o ancora meglio, implementazioni reali su problemi concreti della serie: “this is how I did it”.

Attendo opinioni/linciaggi :).

Gian Maria.

Print | posted on Monday, November 14, 2011 10:09 AM |

Feedback

Gravatar

# re: Framework per DDD

x Gabriele
Esiste il vecchio progetto di Fowler implementato in Java ed esiste NSK, un ottimo esempio in .NET di DDD.
11/14/2011 2:06 PM | raffaeu
Gravatar

# re: Framework per DDD

Esiste anche il progetto di esempio delle navi di Eric Evans, ma se vuoi un esempio di Event Sourcing.... non ci sta praticamente nulla, per CQRS stessa cosa, ancora è molto acerbo come movimento il DDD.
11/14/2011 3:38 PM | alkampfer@nablasoft.com
Gravatar

# re: Framework per DDD

In realtà il problema maggiore è il tempo, :), però qualcosina in mente la ho, assieme con il buon Mauro.
11/15/2011 9:43 AM | alkampfer@nablasoft.com
Gravatar

# re: Framework per DDD

Ciao Giacomo, ho seguto a Bologna la tua presentazione, ed Epic è sicuramente un progetto molto ambizioso e sicuramente interessante.

Penso però che creare un framework veramente generale, che ad esempio possa lavorare bene con Event Sourcing oppure con un ORM tradizionale etc, sia una fatica immensa, e non so quanto tutto possa essere generalizzabile/pluggabile.

Per questo ritengo che, per lo meno a data odierna, il DDD abbia bisogno di casi più semplici e pratici, della serie "io l'event sourcing lo ho implementato cosi", fatto chiaramente da X persone differenti, in modo da ragionare "sul pezzo" e poi scegliere cosa è meglio per la propria situazione.

Detto questo non voglio assolutamente dire che il tuo progetto non sia interessante o fattibile, e anzi, ti auguro un grande in bocca al lupo ;)


11/15/2011 6:46 PM | alkampfer@nablasoft.com
Gravatar

# re: Framework per DDD

Purtroppo infatti le reference implementation spesso sono fatte male, ovvero sono un caso supersemplice che poi in produzione non va. Quello che mi piacerebbe vedere in giro sono reference implementation di BOUNDED CONTEXT reali, quindi di materiale che realmente sta in produzione o che comunque risolve un problema reale, che funzioni, e che sia comprensivo di tutto, dallo storage ad una UI anche se minimale.

Entity framework è un "orm" (ancora tra virgolette), e come dice Brando, troppo spesso nel DDD la gente parla solo di ORM, come se il succo sia tutto li. Noto che spesso, quando il discorso si focalizza molto su NHibernate, EF o altri, la ragione è che si sta ragionando ancora trppo spesso sui "dati" e non sulle "operazioni", poi magari mi sbaglio :). Cmq l'interesse verso il DDD sta crescendo, se son rose fioriranno, ma cmq più vado avanti, più mi rendo conto che i principi del DDD sono semplicemente quelli dell'Object Orientation e che stanno venendo fuori ora, perchè nonstante siano anni che ci sono linguaggi ad oggetti, la maggior parte dlele persone li usa come fossero procedurali :), sempre IMHO naturalmente :).

11/16/2011 9:42 AM | alkampfer@nablasoft.com
Comments have been closed on this topic.

Powered by:
Powered By Subtext Powered By ASP.NET