Pillole Di Domain Driven Design

Summary Una visione in pillole della pratica di disegno del software guidata dal Modello

Pubblicato nella Rubriki Numero 4 - 14 Dic 2006 da GiancarloSudano

Pillola #1: Che cos'è

Un mindset (una forma-mentis), cioè una serie di principi e priorità, atte ad accelerare la progettazione software che ha a che fare con domini di particolare complessità.

Le premesse fondamentali sono:

La maggior parte dei progetti, dovrebbe basarsi su un Dominio, e su una Logica di Dominio.
La progettazione di Domini complessi dovrebbe basarsi su un modello analitico.

Bisogna tener presente che:

Il modello analitico (cioè il risultato del lavoro degli analisti) è uno strumento di sola comprensione.
Un analista poi può usare UML per la visualizzazione del modello stesso.
Il modello non porterà nessun dettaglio implementativo ai fini di non inquinare la comprensione.

L'implementazione di un modello molte volte può allontanarsi notevolmente dalla sua iniziale descrizione.

La Domain Driven Design è una disciplina di progettazione atta quindi a tenere costantemente vicini sia il modello analitico che il modello implementativo.

Pillola #2: Domain modelers

Gli analisti finanziari hanno a che fare numeri.

Gli avvocati hanno a che fare con le leggi.

I Domain Modelers hanno a che fare con la conoscenza. Non fanno altro che acquisire conoscenza dagli Esperti di Dominio (i clienti) e distillare questa conoscenza in modo da selezionare la parte rilevante ai fini dell'effettiva soluzione del problema di business.

Pillola #3: Ubiquitous language

Gli esperti di dominio (i clienti) conoscono i termini del loro campo di conoscenza, ma non conoscono i termini propri dello sviluppo software.

Concordemente gli sviluppatori che utilizzano termini di propri di sviluppo, possono descrivere bene un sistema in termini funzionali ma privo di significato per un esperto di dominio.

Nella Domain Driven Design l'uso di un linguaggio comune tra gli sviluppatori, architetti, analisti ed esperti di dominio è essenziale alla riuscita del progetto.

Il mancato uso di un linguaggio comune rischia di confondere il visione del modello analitico, e della sua implementazione. Peggio ancora può indirizzare verso un refactoring sbagliato.

E' errato altresì pensare che questo linguaggio possa essere definito in modo dettagliato fin dall'inizio del progetto.

Risulta essere invece il risultato di arricchimenti del modello analitico.

Ad ogni cambiamento del modello analitico viene fatto corrispondere un cambiamento nel domain model.

Questo linguaggio sarà utilizzato oltre che tra le varie figure, anche nei diagrammi, nella documentazione e non per ultimo nel codice.

Il modello analitico è quindi la spina dorsale dell'ubiquitous language (cit. "Use the model as the backbone of a language").

Qual'è l'apporto di un developer a questo linguaggio comune?

Come dicevo in questo post...gli sviluppatori hanno sempre a che fare con i domini applicativi dei clienti e riescono talvolta a individuare e risolvere ambiguità e incoerenze difficilmente riconoscibili anche dai clienti stessi.

Pillola #4: Il limite intrinseco dell'UML

Ancora qualche premessa.

E' proprio vero. Provate a fare una riunione per discutere del vostro dominio attorno ad un tavolo, tra developer, esperti di dominio, architetti e chi volete voi, e vedrete che ognuno andrà per la propria strada. Farà le proprie supposizioni e i propri voli pindarici.

Provate a schizzare un grafico alla lavagna con sole 5 classi in UML e fare la stessa riunione con le stesse persone e vi accorgerete della differenza.

Quella sola presenza al centro del tavolo riesce a far tenere l'attenzione sul modello analitico (di cui è una mera rappresentazione), e pone le basi per una corretta evoluzione.

UML presenta però un limite: può diventare mastodontico mostrare il funzionamento del modello.

Lo Static Class Diagram si ferma alle classi, agli attributi e alle loro relazioni. Poi ci vuole anche un Sequence Diagram a mostrare il vero scopo delle funzioni. Ma può non essere sufficiente. Quello che sfugge all'UML stesso è il significato vero e proprio del modello. Purtroppo la visualizzazione grafica di una relazione o una dipendenza non ne esprime il vero significato. Così come una business rules è difficilmente rappresentabile.

Dalla bibbia secondo Eric Evans:

...The diagram's purpose is to help communicate and explain the model.

The code can serve as a repository of the details of the design.

Well-written Java is as expressive as UML in its way...

Pillola #5: Il limite intrinseco del Model Driven Design

Il Model Driven Design, pretenderebbe di poter generare il codice partendo dall'UML. Ed è li che il fallimento ci aspetta dietro l'angolo.

Fare una generazione di codice da UML e poi continuare a mantenere il codice allineato al modello è un lavoro pesante e difficilmente automatizzabile.

Teniamo a mente anche che:

I diagrammi rappresentano una vista del modello analitico. Ma non sono il modello analitico. Per dirla con un detto zen...se qualcuno vi indica la luna con il dito...non confondete il dito con la luna.
E' invece il codice di un progetto (e volendo astrarre, anche il design) che riesce a catturare il modello più finemente. Certe volte è meglio leggere codice parlante che quintali di documentazione (Ogni buon developer nel suo intimo conosce questa verità!).

Il class designer di Visual Studio si discosta da altri tool di modellazione (statica) proprio per il fatto che non è UML che in qualche modo sarà trasformato in codice. E' semplicemente una view grafica sul codice stesso, modificabile interattiva ed intuitiva. E per far questo si è dovuto superare il limite dell'UML in favore dell'adozione di un Domain Specific Language.

Pillola #6: I primi comandamenti

Non essendo presente nella Domain Driven Design un vero e proprio manifesto o dei comandamenti, ho fatto in modo che da un estratto della mia bibbia...se ne potessero tirare fuori alcuni.

Sono generici e saranno completati poi da modalità più specifiche di design, ma devo dire che già espressi in questa forma fanno il loro effetto:

Partizionare le applicazioni in Layer.
Il design dei layer deve garantire la loro coesione.
I Layer dovrebbero dipendere solo da layer sottostanti.
Usare pattern architetturali per garantire un basso accoppiamento di un layer con un altro.
Concentrare tutto il codice che riguarda il Domain Model in un layer specifico. Isolare il questo codice di dominio da responsabilità di interfaccia, applicative, o di infrastruttura.

Ovviamente notiamo che alcuni principi sono fondamentalmente di Object Oriented Design pura.

Un forte accento va però messo nell'isolamento del Domain Layer. Il suo isolamento da responsabilità infrastrutturali, o di visualizzazione, gli da la concreta possibilità di rappresentare in modo efficace il modello analitico. Tutto questo guadagnando in semplicità di lettura, di testabilità e manutenibilità.

Il Domain Layer sarà sempre il collante, tra il modello implementativo e il modello analitico.

Una modifica al domain layer, implica cambiamenti implementativi (sul codice) e concordemente al modello analitico stesso (ad esempio nei vostri diagrammi UML se lo avete rappresentato così).

Pillola #7: Dai comandamenti alle entity poco "responsabili" (o anemiche)

Date queste 5 gemme (soprattutto per l'ultima)...Il risultato a più alto impatto nel vostro codice sarà:

Oggetti di dominio che non avranno più responsabilità specifiche di visualizzazione, binding, persistenza, e varie attività funzionali.

Il loro compito sarà maggiormente concentrato nell'esprimere (nel codice) i concetti del modello analitico.

Vediamo come si può mantenere poco inquinata una Entity del Dominio, delegando a chi di dovere...le proprie responsabilità (ho messo tra parentesi dei framework di esempio, ovviamente che ci possono essere d'aiuto, la cui scelta è puramente tecnlogica, ma dal punto di vista architetturale...l'importante è rispettare la delega)

Responsabilità di Persistenza:

Delegate nel Layer Infrastrutturale di storage (posso usare NHibernate).

Responsabilità di Configurazione, Assemblaggio e Wiring:

Delegate nei Layer infrastrutturali (posso usare Spring.NET)

Responsabilità di Visualizzazione, Ordinamento, Binding:

Delegata nel Layer di UI (posso usare ObjectViews).

Responsabilità di Sicurezza, Transazioni, Logging:

Delegata a configurazioni (posso usare Spring.NET AOP)

Responsabilità di Validazione Contestuale:

Delegata nel Layer di Business/Application (posso usare NRuleValidator o il VAB).

Vuol dire che le entity non devono contenere logica di business?

No. Tuttaltro. Qualsiasi metodo/funzione che non dipenda dai servizi che ho precedentemente delegato può essere contenuto in oggetti di dominio.

A breve un esempio di layering e anche di come possa essere partizionata la logica di business.