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 😉
