alessandro melchiori
() => melkio.OnStage();

Alessandro Melchiori

DDD: i behavior prima di tutto

12 Apr 2012

Molto spesso, come già detto, ci sembra di applicare DDD, ci autoconvinciamo della cosa (anche perché ultimamente se non fai DDD, non sei nessuno :-) ), ma siamo ben lontani dall’applicarlo.

Il primo, vero, campanello d’allarme, se di allarme vogliamo parlare, lo possiamo percepire da come è fatto il nostro dominio: se non abbiamo un domain model, non stiamo sicuramente facendo DDD. Avere un domain model, non significa che stiamo facendo DDD. Riporto la definizione originale, a scanso di equivoci, di cosa un domain model dovrebbe essere:

“An object model of the domain that incorporates both behavior and data. [Martin Fowler]”

Ragazzi non ci si scappa: quel both è la parte più importante della definizione. E dato che sul data non ci piove (e non manca mai), è la parte behavior che fa la differenza, che è l’ago della bilancia che ci permette di asserire con un po’ più di certezza di aver intrapreso la strada giusta (ovviamente se la strada che vogliamo intraprendere è quella del DDD)

Dire: “ho un domain model anemico” è una frase senza senso. Un domain model senza comportamento, non è un domain model. Punto. Un object model, come quello dell’immagine seguente, dove la parte data la fa da padrone, nel senso che di behavior non se ne vedono, non è DDD-style e non ci permette di gestire la complessità del business che dobbiamo modellare. Se la complessità non c’è, siamo a posto, ma se c’è logica, più o meno complessa, potrebbe essere l’inizio della fine.

Se poi pensiamo di delegare la consistenza di parti del nostro modello a layer differenti (per esempio il service layer) rispetto a quello del domain model, stiamo rischiando (è molto più di un rischio) di “rompere” uno dei principi caratterizzanti che guidano lo sviluppo in DDD: la definizione degli aggregati.

Se vogliamo applicare DDD, tutto parte da lì, dalla corretta definizione degli aggregati e dall’esposizione di behavior dall’aggregato. Dato che questo è uno dei principi basilari, ma anche uno di quelli più difficili da “implementare”, quello che solitamente mi trovo a far fare a chi mi presenta un object model completamente anemico è: “togliamo tutte le proprietà pubbliche ed esponiamo funzionalità”…poi chiamo un medico, perché solitamente metà del team è svenuto :-)

Questa “prova di coraggio” tipicamente si scontra con il modus-operandi di gran parte dei team con cui mi trovo ad interagire. Indipendentemente dalla propensione al massiccio refactoring, gli scogli da superare sono comunque parecchi e toccano vari aspetti della nostra applicazione: la parte di persistenza, gli unit test, i tool da utilizzare…

Insomma c’è tanta carne al fuoco, nelle prossime puntate vedremo di dettagliare un po’ meglio e di entrare un po’ più nello specifico…se poi non vi ho annoiato troppo, rinnovo l’invito per il primo meeting organizzato da guisa: lì ne vedremo veramente delle belle.

Accorrete numerosi ;-)

Comments