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.