DDD book by Eric Evans

“A document must be involved in project activities” — Eric Evans

Inutile nasconderselo: una delle cose più difficili da mettere in pratica è l’allineamento fra la documentazione (requisiti e design) ed implementazione. Di approcci ce ne sono tanti ma uno dei più interessanti è il DDD. Non si tratta di un vero e proprio processo software, più o meno formalizzato, ma di una differente prospettiva che pone il modello (il dominio, ossia entità e relazioni, ossia classi e associazioni) al centro dello sviluppo (inteso in senso lato, dalla discussione continua dei requisiti al codice).

Essenzialmente:

  1. si definisce (e si arricchisce/modifica costantemente) un linguaggio comune tra sviluppatori e committenti (Ubiquitous Language) il cui scopo è fornire il vocabolario per il modello e per tutte le interazioni umane.
  2. Progetto e implementazione fanno costantemente riferimento al dominio: se un dominio non è implementabile allora perde di valore! Nella pratica questo porta ad analizzare (discutere) più a fondo il dominio con il risultato di semplificare il dominio: sviluppatori e committenti interagiscono, il software si modifica per meglio aderire alle esigenze man man che esse emergono dal fog of ideas ma queste idee sono effettivamente realizzabili
  3. Si fa uso massiccio di un insieme di pattern e best practices (chiamati Building Blocks) nella strutturazione dell’applicazione al fine di isolare il modello dai requisiti sistemici che lo sporcherebbero (quindi: layered architecture, entities, value objects, services, repositories, …).

Molti concetti sono, in effetti, quelli che sono alla base della normale buona programmazione ma che sono particolarmente importanti in un processo software agile dove la qualità dell’elemento umano (la cultura dello sviluppatore, intesa sia come conoscenze tecniche che del dominio) è (finalmente, dico io) messa al centro della costruzione del software.

Effettivamente mentre un approccio document-centric (cioè che produce molta “carta”) tende a modellare lo sviluppo software come un processo manufatturiero “qualsiasi” dove operai poco skillati realizzano progetti di ingegneri skillati, un approccio agile (o code-centric) ha bisogno di personale ugualmente versato (le specializzazioni sono scontate ed emergono naturalmente ma non si tratta di differenziazioni rigide ma di opportunità per il project manager): in ogni caso non sono ammissibili sviluppatori-analisti che ignorano l’implementazione e “code-monkeys” che ignorano il dominio.
Il libro che voglio segnalare è Domain Driven Design, Tackling Complexity in the Heart of Software di Eric Evans: praticamente il libro clue per questo argomento e consigliato senza esclusione da mostri sacri come Martin Fowler e Kent Beck. Ok, non è leggero come Topolino ma si trovano degli interessanti spunti per la nostra professione … 😀

Do you know Domain Driven Design?

3 thoughts on “Do you know Domain Driven Design?

  • 16 November 2006 at 19:27
    Permalink

    visto che è il primo, ti perdoniamo sia la lunghezza, sia la “sborononaggine” del post.
    scherzi a parte, interessante

    Reply
  • 16 November 2006 at 19:45
    Permalink

    non crederete mica che l’ho letto davvero tutto i post?!? 😛

    Reply
  • 16 November 2006 at 20:10
    Permalink

    Alla grande, Mario.
    Dalla descrizione che hai fatto, un po’ suona come dejavu se non aria fritta. Mi ha convinto più il finale, con il richiamo all’agilità. Poi, ora che ho saputo che il libro è consigliato anche da Martin Fowler e Kent Beck, un po’ mi hai incuriosito. Metteremo il libro nella prossima lista della spesa. Grazie.

    Reply

Leave a Reply to Fabiolino Cancel reply

Your email address will not be published. Required fields are marked *