Domain Data Driven

in Architetture Software

Domain Driven Design

Reading Time: 2 minutes

Nello sviluppo di un software è fondamentale definire un buon design consente di definire l’architettura in maniera comprensibile e spesso facilmente estendibile. Nello sviluppo di applicazioni complesse, infatti, non sempre il codice viene scritto per essere facilmente compreso e soprattutto esteso. I fattori di complessità di un software sono tipicamente di carattere tecnico, ma molto spesso la complessità è intreseca al dominio in cui il software dovrà operare.

Il Domain Driven Design (DDD), termine che è stato coniato da Eric Evans in un libro omonimo, è un approccio per ha come obiettivo quello di velocizzare e semplificare lo sviluppo di applicazioni complesse.

Quando utilizzarlo

L’applicazione del DDD è indicata per tutte quelle attività di sviluppo dove l’apprendimento del dominio avviene per step. Inoltre è molto indicato in tutti gli sviluppi dove le logiche del business sono complesse e tendono ad evolvere nel tempo. E, ovviamente, in tutti quei processi di sviluppo che utilizzano la programmazione ad oggetti e che utilizzano concetti come il refactoring, Ioc ecc…

Quando non utilizzarlo

Se il progetto da realizzare è piuttosto semplice e soprattutto non evolve nel tempo, non è consigliabile l’utilizzo di DDD. Evidentemente anche in tutti quei progetti che non evolgono nel tempo.

Terminologia

Nella definizione di un progetto DDD viene utilizzata la seguente terminologia:

  • Dominio: argomento al quale l’utente applica un programma è appunto il dominio del software.
  • Modello: un sistema di astrazioni che descrive determinati aspetti di un dominio e che può essere usato per risolvere problemi correlati allo stesso
  • Ubiquitous language: una semantica strutturata attorno al modello del dominio e usato da tutti i membri del team per collegare tutte le attività del team con il software.
  • Context: il contesto nel quale una parola o espressione prende significato.

Principi

Per poter utilizzare il DDD è necessario tenere a mente due principi fondamentali:

  • il focus dello sviluppo deve essere impostato sul dominio dell’applicazione e sulla sua logica
  • tutte le progettazioni complesse devono basarsi su un modello nel dominio

Da un punto di vista architetturale, l’applicazione da realizzare viene scomposta in una serie di oggetti che rappresentano il modello del dominio applicativo, utilizzando dati e comportamenti caratteristici della business logic della nostra applicazione.

Molto spesso nello sviluppo di applicazioni semplici, esiste una corrispondenza 1-a-1 tra modello e tabelle del nostro database. Tutto questo non è ovviamente riproducibile all’interno di strutture più complesse, dove il mapping tra data layer e domain model viene realizzato tramite tool specifici, come ad esempio gli ORM (es. Entity Framework).

“An object model of the domain that incorporates both behavior and data” Fowler

Una classe .NET rappresenta un object model: una volta creati gli oggetti possiamo collegarli tra loro utilizzando relazioni e gerarchie. Nel pattern di Fowler, ciò significa creare il grafo di interconnessione.

Se i domain model non rispecchiano in maniera esaustiva le regole indicate da Fowler (ed Evans), ci troviamo di fronte a quello che viene definito Anemic Domain Model. Alcuni esempi di Anemic Domain Model sono:

  • la logica dell’applicazione viene inglobata direttamente all’interno di setters e non in metodi dedicati
  • classi in cui sono presenti solo getters e setters, e non sono presenti metodi
  • ad una classe corrisponde una ed una sola tabella

In uno dei prossimi post analizzeremoanche il concetto di Entity.